GONE PLAN 



so, 



Then There Was a 
Doughnut and a Snake... 



I guess I'm getting older. While I 
used to dream about showing up 
for final exams totally unprepared 
(well, not so much "dream" as 
"remember"), the other night I 
had a new kind of anxiety dream. 
Apparently I'm more anxious 
about the future of digital enter- 
tainment than I thought. 

kay, my wife Tina and I are in 
my neighbor's backyard in full scuba 
gear. We're looking for the hole in my 
drysuit that flooded the previous week- 
end. I pick up the phone and it's this 
sleazy movie producer I know, and he's 
panicked. 

"Val Kilmer has frozen to death! 
And they're after me next! You have 
to—" H e cries before being cut off. I 
know, although M ike and I had been in 
a perfectly legitimate deal to make an 
interactive game, that he's somehow 
involved me in one of his more colorful 
movie-financing schemes. I tell Tina 
that we have to leave immediately 
because we're in imminent danger. 

So I take her hand and we start 
moving down the row of chairs in an 
empty Candlestick Park. Samuel L. 
Jackson is there, reading the note left 
by the terrorists, who have him in their 
sniper scopes but let him go because 
they don't know where Bruce W illis is. 
It turns out that the chairs are sur- 
rounding the pool John L illy used to do 
dolphin communication research in. 
Standing knee-deep in the pool is my 
brother, holding up his 16-month-old 
son, who's babbling but doesn't talk. A 
bottlenose dolphin swims by, and I 
wonder if the entropy of dolphin sig- 
nalling shares characteristics with other 
signals with complex meanings, such as 
human language or D N A . 

But it turns out that this is not 
John Lilly's dolphin pool, but an audi- 
torium where they're previewing W in- 



dows 95 for $25 a ticket. T hat's just 
ridiculous, so Tina and I leave the audi- 
torium for the lobby of our local Pacific 
Regency theater. Tina tells me to buy 
the popcorn while she goes ahead and 
gets us seats. But wouldn't you know it, 
just as I 'm getting in line, Steven Spiel- 
berg walks by. 

M y keen journalistic instinct kicks 
in and I ask Steven if I could ask him a 
few questions sometime for the maga- 
zine. H e agrees and I tell him I'll call 
him in a few days when I'm prepared. 
Steven shakes his head and says it's now 
or never. I get tongue-tied, but the 
screenwriter W illiam G oldman taps me 
on the shoulder and says, "It's all 
changed since Jaws." Seizing on that 
(and forgetting that, given my druthers 
in real life I'd rather meet Goldman 
than Spielberg) I ask Spielberg, "Will a 
video game ever give the director the 
kind of control over the experience 
needed to make a Jaws? r a Schindler's 
List?" 

H ere, unfortunately, is where my 
dream failed me. Spielberg answered 
me in depth, but apparently my subcon- 
scious gave up on second-guessing real- 
ity and I couldn't understand his sen- 
tences. I got so frustrated trying to 
understand him that I thrashed myself 
into waking. 

D reams are our most powerful fan- 
tasies, with the power to weave deep 
allegory into our mundane personal 
experiences. M y dream was subjectively 
a complex pondering on the nature of 
communication and narrative. But even 
if you can follow the metaphorical 
thread of my dream, and the unusual 
all-star cast creates some resonance in 
you, another person's dream is at best 
an amusing and inefficient narrative. 
W hy? The three most important rea- 
sons are the personal symbolic mean- 
ing, the dismissal of explanatory transi- 
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GONE PLAN 



tions, and the personal nature of the 
dream experience. You dream alone. 

C inema is the second most power- 
ful narrative force we experience. I'd 
give the nod to one-on-one story- 
telling, but raconteurs are sadly rare, 
and professional storytellers make their 
meager livings almost exclusively with 
children. Television affects us more, 
but as a mental massage, not as a narra- 
tive. L iterature is broader, deeper, and 
subtler, but no artists have as much 
control over the audience as moviemak- 
ers. A nd there has never been a director 
more in tune with the nature of that 
power than Spielberg. 

I'm not saying that H ollywood is 
producing better movies than it has in 
the past or that Spielberg is artistically 
head-and-shoulders above every direc- 
tor, living or dead. But I do assert that 
audience control has never been as pol- 
ished. I'll even commit sacrilege and 
say that Spielberg routinely plays the 
audience better than H itchcock. 

W hat about the potential of digi- 
tal entertainment? The engagement of 
the player is so focused that peripheral 
elements seem to be useless — if it's 
not part of the gameplay, it's not part 
of the game. Putting the player in con- 
trol seems central, but every other form 
of fiction relies on plots driven by the 
narrator, not the listener. And the best 
fiction relies on plot points that appear 
inevitable, but only in retrospect. W ith 
the possible exception of M yst, no 
game has achieved that. 

It's becoming cliche to equate cur- 
rent interactive entertainment with the 
early days of film, when films were 
spectacle with little or no plot. The 
comparison is generally used to reassure 
us that we'll get those talents able to 
combine art and popularity— the Grif- 
fiths, E isensteins, H itchcocks, W ilders, 
Scorseses, and Spielbergs. But will we, 
even in a hundred years? Even my sub- 
conscious doesn't know. 

Your Hour's Up 

Before being wildly distracted by this 
dream, I had planned to write this edi- 
torial on the E 3 show in LosAngeles, a 
show that couldn't contrast more with 



the C omputer G ame D eveloper's C on- 
ference I wrote about in our last issue 
("Brain G oes W hoosh," G ame Plan, 
June/July 1995). E3 was an awesome 
spectacle: 750,000 square feet of exhi- 
bition space devoted to the interactive 
entertainment industry. Of that, about 
700,000 square feet seemed devoted to 
fighting games— now in flat-shaded, 
three-dimensional polygons! The lack 
of creativity in the cartridge industry 
was overwhelming. The home comput- 
er CD-ROM game is where all the 
innovation is. I felt like I was seeing 
Comdex in 1984— with mainframe 
vendors amused at the notion that a 
general purpose desktop computer 
could take over from their specialized 
hardware. 

A s C hris H ecker points out in this 
month's "Behind the Screen," the new 
generation of cartridge machines on 
display were technically less than awe- 
inspiring. M y first reaction to N inten- 
do's decision not to unveil the U Itra 64 
was that it was disastrous not to show a 
next-generation machine. But after 
seeing the competition (and after a 
couple of quiet meetings off the show 
floor), I think that Nintendo is the 
once and future king of the cartridge 
market. 

It's not a great surprise that I 
ended up dreaming about Hollywood 
after attending E3; H ollywood and the 
cartridge industry are staring with 
incestuous lust into each other's eyes, 
totally missing the fact that the home 
computer is going to drive the U.S. 
gaming industry and that U.S. software 
developers are poised to become as 
dominant in the entertainment software 
industry as they are in the applications 
industry. Those developers aren't inter- 
ested in shelling out tens of thousands 
of dollars for a development license, 
much less millions; they're aiming for 
the PC market, knowing that if they 
deliver a Doom, a Wing Commander 
1 1 1 , or a M agic C arpet, the cartridge 
manufacturers will fight to get them, 
with their checkbooks open. Now 
there's a dream to lull you to sleep. 

F inally, I 'd like to once again 
thank those who made the first year of 



Game Developer such a success. Since 
our last issue, G ame D ev eloper was hon- 
ored by the Computer Press Associa- 
tion as a runner-up for "Rookie of the 
Year" and won the WPA's "Best New 
M agazine-T rade" M aggie Award. 
W ithout the volunteer efforts of the 
editorial staff in the first year and the 
great writers who took a chance with 
us, we wouldn't have had a magazine, 
but without you, the readers, we 
wouldn't have had a success. T he M ag- 
gie belongs to them. But I get to hold 
on to it. ■ 

L arry 'B rien 
E ditor 



ERRATA 

Okay, so we made a few errors in 
our last issue. They all appeared 
in "Perspective Texture M ap- 
ping Part II: Rasterization," 
Chris H ecker's June/July installment 
of Behind the Screen. 

• Equation 1 on page 19 has a mis- 
placed parenthesis that renders it 
incorrect. The equation should read 
as: 



yi - y, 



(y - y ) + x c 



• n page 19, C hris H ecker wrote: 

"If we're exactly on an integer 
pixel center we will light the pixel, 
but if our x is at all greater than 
the integer— to the left of the pixel 
center— the ceiling will bump us up 
to the next pixel that's strictly 
inside the edge." 
It should read: 

"...to the right of the pixel center." 

• ren Patashnik and Ronald L. 
Graham were credited with having 
written Concrete M athemati cs. D.E. 
Knuth was also an author of the 
book. 
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CROSSFIRE 



The Window s 
95 Game Plan 



Alex Dunne 



The launch of 
Windows 95 is weeks 



oim|. Hr some 



in the coming months 
it's going to alter your 
development plans. 



you prepare 



for game develop- 
ment's newest arena? 



Characterizing your develop- 
ment efforts for the coming 
six months will require a little 
Q and A : Will you migrate 
all game development over to 
Windows 95 immediately, 
hold out and continue to 
work on DOS- based games, 
or take the middle-of-the-road 
approach as you divert some DOS 
development staff to W indows 95 
efforts? 

I talked to a sample of game devel- 
opers in the industry, and found that 
there's no prevailing route. Also, I found 
no correlation between the choices com- 
panies made and the size of their com- 
pany. One question many companies 
wanted an answer to, though, was how 
quickly W indows 95 would be adopted 
by the game market. 



Moore's Launch Curve 

There's a theory that might help answer 
this question. In a recent column in Soft- 
ware Development ("The Launch 
C hasm," T ools of the T rade, J uly 1995) 
Warren Keuffel describes G eoffrey 
M oore's concept of "the launch chasm." 
This phenomenon occurs after a product 
release in high-tech markets, and by 
studying it you get a sense of what will 
likely happen once W indows 95 becomes 
available. 

M oore said that the market for a 
given high-tech product can be repre- 
sented by a bell curve made up of five 
distinct categories of consumers, each of 
which roughly corresponds to one stan- 
dard deviation. T hese groupings are 
called (in order of adoption) innovators, 
early adopters, early majority, late majori- 
ty, and laggards. As shown in Figure 1, 



Figure 1. Moore's Launch Curve 
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Figure 2. Software Installed Base 
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Source: Dataquest 

the first two groups of consumers typical- 
ly understand and are enthusiastic about 
new technology and actively seek it out. 
Unfortunately this group is relatively 
small. Beginning with the early majority, 
skepticism increases causing longer and 
longer delays before people adopt the new 
technology. 

Leading the Way 

Although game developers releasing 
W indows 95 products this year will ini- 
tially face a market of limited size (com- 
pared to the DOS market), there's an 
upside: this smaller market of innovators 
and early adopters will consist of a pro- 
portionately high amount of hard-core 
gamers, as most devoted gamers typically 
live on the technological "cutting edge." 

Companies moving development 
quickly over to W indows 95 will get a 
head start in a number of areas over those 
who stick with the tried-and-true DOS 
world. I n addition to the skills developers 
learn, the benefits will propagate down to 
staff in marketing, sales, documentation 
writers, and most importantly, employees 
in technical support. 

Bringing Up the Rear 

T he majority of consumers will take 
longer to adopt W indows 95. Skepticism, 
ignorance, apathy, dedication to the old 
way of doing things, or simply insufficient 
hardware will hold most people back for 



Year 



at least six months, if not longer. 
D ataquest has projected the growth of the 
W indows 95 installed base as seen in Fig- 
ure 2. T he company anticipates the 
installed base of W indows 95 surpassing 
that of W indows 3.1 and D S combined 
sometime in mid- 1996. Dataquest's pro- 
jections for shipments of W indows 95 are 
depicted in Figure 3, which illustrates 
that shipments of W indows 95 will sur- 
pass shipments of W indows 3.1 around 
the end of this year. 

One interesting aspect about 
D ataquest's predictions is its positive out- 
look for W indows 95 through the end of 
the decade. W indows 95's successor, 
Cairo, is scheduled for release in two to 
three years, which will take some of the 
wind from W indows 95's sails. Beginning 
in 1998, I 'd predict fewer sales than 
D ataquest projects. 

For now however, DOS is with us, 
and I suspect it will remain with many 
consumers for years (my mother still uses 
an A pple ME, so I 'm sure that some peo- 
ple will be working on 386s in the year 
2010). M any companies are banking on 
the DOS market for the foreseeable 
future, and I have no doubt that this mar- 
ket will continue to be lucrative for years. 
The majority of consumers who initially 
shun Windows 95 may not be the 
"digerati" who consume games on a 
weekly basis, but many are consistent, if 
not frequent, game buyers. In addition, 



W indows 95's backwards compatibility 
keeps both markets open to your product: 
you'll sell to both the early adopters and 
the hold offs. 

Staying the Course 

T his is the route that N ova L ogic is tak- 
ing. I spoke with David Seeholzer, vice 
president of software, and asked him how 
many W indows 95 games the company 
would be releasing this year. 

"Zero," Seeholzer replied. "We're a 
pretty small company and don't have a 
group of R&D people sitting around and 
playing with stuff. All of our people are 
pretty much working on our core prod- 
ucts that are on the verge of getting 
released within the next couple of months 
or next year. As we have programmers 
come free from projects in the next couple 
of months, we'll have one or two of them 
play around with W indows 95 and evalu- 
ate it. W e're always looking at new 
opportunities to do games in a W indows 
environment. But right now we just 
haven't spared the manpower to look into 
it." 

I inquired whether this meant that 
DOS would continue to be N ova L ogic's 
primary platform for the foreseeable 
future. "Yes, though I think we recognize 
that DOS isn't going to last forever," See- 
holzer said. 

T here are things that we like about 
D O S in terms of doing high performance 
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games, it just doesn't get in your way. 
And the original W indows [3.x] got in 
your way big time. W inG was an effort to 
bridge the gap, which was successful on a 
few fronts, but not on as many as we 
would have liked. W indows 95 is trying 
some additional things, but it still has 
some major issues that we're concerned 
about. It's our assumption that the trend 
will continue, though-that eventually, 
there will be a W indows environment 
that we'll feel comfortable doing our kind 
of games on. N ot to mention the fact that 
DOS will probably become an unviable 
way to publish. 

"W e know that there's change ahead, 
but we're currently selling our products to 
the huge installed base of people who can 
run DOS, whether or not they also run 
W indows... It's quite possible that we 
would have something next year. Because 
we are small, we're able to move pretty 
quickly on things, and it's not at all 
unlikely, as we finish our current round of 
products that we'd look into it, figure out 
what we could do, and start to [develop 
for W indows 95]," Seeholzer said. 

H owever, if your shop is one that 
will continue a solid effort in the DOS 
development world, you may be sacrific- 
ing an important technological lead to 
those companies that dive into W indows 
95 and train their staff early. Don't give 
away a head start if you don't have to; 
small pilot projects might be the answer. 



Getting the Feet Wet 

One game developer that seems to be 
taking this route, though the company 
doesn't consider its game a "pilot pro- 
ject" as such, is LucasArts. Tom Sarris 
of LucasArts described the company's 
first W indows 95 title, "I ndiana Jones 
and H is D esktop Adventures." 

"I hate to use this word, but it's a 
'simpler' title than perhaps what you're 
used to seeing from us," Sarris 
remarked. "H ere's a game that you can 
play in between a half hour and an 
hour. You can load it onto your PC and 
goof around with it when you have an 
extra half hour or so. It's actually just on 
one high-density floppy disk. It's a top- 
down view, much like [the 16- bit N in- 
tendo game] legend ofZelda/and has 
over one billion game play scenarios." 

L ucasA rts's "I ndiana Jones and 
H is D esktop Adventures" is the only 
W indows 95 title that the company is 
planning to release this year, and may 
turn into a series of games. 

Taking the Plunge 

Finally, I spoke to a company that's 
decided to dive straight into the Win- 
dows 95 arena. San Francisco- based 47- 
Tek released a sophisticated 3D fight- 
ing game last year called Sento, which 
was optimized for M atrox video accel- 
erator cards. M ark H irsch, the presi- 
dent of 47-Tek, said that the company 



would finish up 1995 with one more 
DOS game and then is calling it quits 
with that platform. 

"W e're going to do three titles next 
year and we'll do a W indows 95 version 
of at least two of them," H irsch said. 
"The other three will go on the [Sony] 
PlayStation, [Sega] Saturn, maybe 
[Nintendo] Ultra64." 

W hen asked if he considered DOS 
dead with the release of W indows 95, 
H irsch gave a straight and simple, 
"Yes." H is company is using the Reality 
Lab 3D API contained in the W indows 
95 G ame SD K, and will design upcom- 
ing titles to support accelerators that 
conform to the 3D DDI standard. 

Both 47-Tek and Nova Logic are 
small companies, so it makes sense for 
them to concentrate limited resources 
on specific technologies. The fewer 
platforms they are divided among, the 
more quickly they'll exploit the power 
of those platforms. LucasArts, on the 
other hand, has a larger staff of devel- 
opers and can afford to divert resources 
in more directions without as large a 
sacrifice to their overall development 
efforts. 

W hat are your plans for game 
development over the next six to twelve 
months? Drop me a line and tell me 
about your experiences so far or strate- 
gies your shop is using to prepare for 
the move to Windows 95. ■ 



Figure 3. Software Shipments 
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Poser, Dude! 



Nicole Claro 
Barbara Hanscome 

New Bit Blasts 
features! "The Buzz" is 
a roundup of pertinent 
corporate news, 
"Schmooze News" is 
industry gossip (you 
just might see yourself 
in there), Vfetch this 
space for more new 
and exciting things, 



■ 1 M 3 " ' <I10W difficult 

■ H W n ^ e t0 create li^like 

I II Mjmans in games and mul- 
111 l me d' a applications (we've 

II I Biscussed tough hair situa- 

■ I lfcons here before, you might 
V Urecall). Fractal Design 

■ MCorp. recently introduced 
Poser, an application that lets you do 
electronic "life drawing." 

Poser is designed to work closely 
with other two- and three-dimensional 
applications and provides stylized mod- 
els—both male and female— that can be 
moved, modified, shaped into any pose, 
and viewed from any angle. It features a 
choice of body sizes (from infant to adult 
to superhero) and direct figure manipu- 
lation—which means when you move a 
body part, all connected parts will auto- 
matically move accordingly. nee you've 
shaped your model, you can apply multi- 
ple light sources and bump and texture 
maps to create a fully rendered human 
model. The software runs on M acintosh 
and Power M acintosh and will be avail- 
able through A ugust 31, 1995 for $99. 

■ For more information contact: 
Fractal Design Corp. 
335 Spreckels Dr. 
Aptos, Calif. 95003 
Tel: (408) 688-5300 

Multimedia galore 

M Factory has announced mTropolis, a 
fully object-oriented development system 
for multimedia applications. Object ori- 
entation lets artists rapidly create com- 
plex environments and store, share, and 
reuse any object or combination of 
objects, predefined or user created. It has 
a fully integrated debugger and multi- 



platform portability for authoring and 
playback. mTropolis also has an open 
architecture, which lets you transparently 
and smoothly enhance your system. 
mFusion, the scalable technology at the 
core of mTropolis allows you to create 
titles that execute extremely fast, even on 
lower-end platforms. mTropolis will ini- 
tially be available as an editor for M acin- 
tosh and Power M acintosh and a player 
for M acintosh, Power M acintosh, and 
W indows 3.x. Suggested retail price is 
$4,995 for single- seat units. 

■ For more information contact: 
mFactory Inc. 

1440 C hapin Ave. 
Suite #200 

Burlingame, Calif. 94010 
Tel: (415) 548-0600 

Lightning Fast 

Criterion Software has announced Ren- 
derW are Lightning. The real-time 
three-dimensional graphics games library 
was specifically created for development 
on many platforms including DOS, 
W indows 95, and Power M acintosh. It 
features fast software rendering on PCs, 
support for three-dimensional accelera- 
tors on PCs and three-dimensional con- 
soles, an easy-to-use A PI , powerful 
importing tools, and automatic cross- 
platform support. RenderWare Light- 
ning costs $995 for a personal license 
and $10,000 for a commercial license. 

■ For more information contact: 
C riterion Software 

17-20 Frederick Sanger Rd. 
Guildford, Surrey 
GU2 5YD, U.K. 
Tel: (408) 749-0493 
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Yamaha Breaks the Bank 

Yamaha's new YGV612 three-dimen- 
sional graphics controller chip features 
texture mapping, Gouraud shading, and 
Z buffering. Geared toward DOS and 
W indows 95 game developers, the new 
chip lets your games run in 640-by-480, 
64-bit colors with high resolutions. It 
supports a DRAM frame buffer, direct 
PCI bus support, and integrated DA C. It 
is currently available in sample quantities 
for $40. You can't beat that with a stick! 

■ For more information contact: 
Yamaha Systems Tech. Inc. 
100 Century Center Ct. 
San J ose, Calif. 95112 
Tel: (408) 467-2300 



Genre Busters 



The untapped market of female teens 
might not go for the traditional shoot-em- 
up game, but will it go for the "social 
adventure"? r intensive personality analy- 
sis? T hat's what two game developers tar- 
geting female teens are hoping for. 

At press time, G ames for H er— a 
new division of A merican L aser G ames— 
was planning the release of its first title, 
M cKenzieand Co. According to thecom- 
pany's press materials, the title is aimed at 
female gamers aged 9 to 15 and will treat 
players to the "real life dilemmas that 
make going to an all-American high 
school such an adventure." With the help 
of a CJ-17 jeep named M cKenzie and a 
band of wacky pals, the player must suc- 
cessfully juggle the demands of school, 
romance, friends, jobs, and family by 
avoiding "bad" decisions throughout the 
game, such as cutting class or lying to par- 
ents. The player also gets to establish a 




Interplay is all over the map. The company has announced an 
agreement with GEnie nline Services to develop two games avail- 
able exclusively on GEnie for six months. In August, the first title, a 
deluxe version of Descent, originally developed by Parallax studios, 
will makes its online debut on GEnie. In M ay, Interplay acquired 
Shiny Entertainment, makers of the huge hit Earthworm J im. This 
marked Interplay's first major acquisition. 

Nintendo's got two new deals going. The company has entered into 
an ecxlusive agreement with M ultigen, under which M ultigen will 
create three-dimensional development tools for N intendo's 64-bit 
machine, the Ultra 64. One of the users of those tools will probably 
be Rare, a company based in the U.K., which will develop a series 
of new 16-bit and 64-bit games for the Ultra 64 and other Nintendo 
platforms as well as games for Game Boy and Virtual Boy. Rare, 
which collaborated with Nintendo on the 1994 game Donkey Kong 
C ountry, is the first video game development company outside of 
J apan that N intendo has invested in. 

Leo the Lion has gone digital. M ajor film studio M GM recently 
announced the inception of M GM Interactive, a new multimedia 
arm of the organization. The new division will produce multiplatform 
and online titles (some new, some based on existing material) on its 
own and in conjunction with various other companies. 



relationship with the boy of her dreams 
and shop for a prom outfit with an elabo- 
rate "shopping engine" featuring 400 
clothing options provided by U rban ut- 
fitter and L imited 1 1 stores. 

Reading the game description, you 
can't help but wonder if M cKenzie and 
Co. could be the CD -ROM equivalent of 
the Brady Bunch, feeding kids the illusion 
of an ideal teen world that doesn't exist. 
Folks sensitive to gender stereotyping 
might be appalled at the game's shopping 
engine. And where are the real teen dilem- 
mas of the 90s— drugs, sex, teen pregnan- 
cy, interracial dating, even the complex 
issues surrounding tattoos and nipple rings? 

G ames for H er's director of market- 
ing, Patricia Flanigan, argues that while 
these issues are real for today's teens, they 
aren't necessarily what young women want 
in a game. The "social adventure" themes 
featured in M cKenzieand Co.— school, 
romance, career aspirations, and friends- 
were determined from intensive focus 
group research with girls from a wide 
range of socio-economic backgrounds in 



Albuquerque, N .M . "It's what the girls tell 
us they like," says F lanigan. T he world is 
tough for teens, and I think something like 
this allows them to escape and to have 
fun." Flanigan says the social adventure is 
just one of four genres G ames for H er has 
developed for teen women: mystery is 
another; Flanigan will not reveal the other 
two at this time. 

F lanigan hopes to explore the heavier 
side of teen life in G ames for H er's new 
online service H erOnLine, a joint venture 
with teen book publisher Daniel Weiss 
Associates Inc. The new service, which at 
press time was scheduled to premiere in 
late summer, will feature chat rooms and 
opportunities for teen women to hook up 
with electronic pen pals and other 
M cKenzie gamers. 

Flanigan is also being aggressive in 
trying to open new marketing channels for 
girls games, placing the title in outlets 
other than computer stores. M cKenzie 
and Co.'s launch will begin with a national 
mall tour and will include several alliances 
and point-of-purchase tie-ins with retailers 
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Game Developer's Conference Doubles again... More than 2,400 atten- 
dees converged on the Santa Clara Westin April 22-25 for the 7th Annual Computer 
Game Developers Conference (CGDC). Rival operating system vendors M icrosoft 
(Windows 95) and IBM (OS/2 Warp) were both out in force, giving goodies to devel- 
opers. Apparently, the next killer game may propel its operating system into top posi- 
tion and both companies are doing their best to woo game developers. It was a great 
deal for people who wanted to load a few extra operating systems on their computer. 

Logitech again threw the opening night bash with the ever popular velcro wall peo- 
ple-throw, munchies, and libations. It was difficult to find friends as the room was 
dark, the spotlights blinding and the music deafening. Industry veterans moved out 
into the corridor and to the hotel bar to schmooze where they could be seen (and 
heard!) 

The unscheduled but traditional jam session at the CGDC spilled over into an extra 
nightwith ourtalented digital musicians going analog to the delight of partying 
gamers. 

On stage were Dave Schultz (DBS M usic) and Dave Albert (Sega). Brian 
Moriarty (M path) and George Sanger (Big Fat) provided vocals. Michael 
Land (LucasArts) and Mark Miller (Sega) played bass. Neal Grandstaff 

(Dynamix) was on drums and vocals. 

Guitarists included Craig Utterbach, Charlie Albert, David Albert (Sega), 
and J im Donfrio (Dijon). Burke Trieschmann blew harmonica. Rob Wallace 

(Wallace Sound & Music) and Alexis Utterman (DeMaria Studios) traded off atthe 
keyboard. Don Griffen (Computer Music Consulting) did the honors on trumpet. 

Microsoft Woos Game Developers... M icrosoft rented Great America for its 
game developer guests. After dropping over The Edge a few times, developers were 
softened up for M icrosoft's Game evangelist, Alex St. J ohn, whose dynamic pre- 
sentation (with backing from the Game SDK programmers acting as a sort of Geek 
Chorus) was designed to convince developers that Windows 95 will propel the PC in 
to game ascendancy. The day after this awesome party, M icrosoft held a seminar for 
developers who want to use the M icrosoft Game SDK. A great time was had by all 
and M icrosoft proved it could relate to game developers on their own level after all. 

Nintendo Postpones 64-bit Gameplayer... Nintendo's Ultra 64 next- 
generation machine won't be released as planned for C hristmas season, but the 
delay could hurt competitors as much as it could N intendo, with a number of buyers 
likely to wait until all the new machines are available for comparative shopping. The 
game system is intended to sell for about $250 and to offer performance approaching 
that of $20,000 workstations. The major concern I've heard about the U Itra 64 is the 
cost of the individual game cartridges: because of the large amount of RAM in the 
cartridges, they will be substantially higher than the competition's games, which will 
ship on CD-ROMs. 

The Word from E3... The first Electronic Entertainment Expo in Los 

Angeles had more than 4,000 attendees. W ith a surprise announcement at E3, Sega 
began shipping the Saturn to American markets at the beginning of E3 weekend. 
Countering with a surprise of its own, Sony announced that while the Playstation 
will not ship until September, it will retail at $299, a solid slap at the $399 price tag of 
Sega's Saturn. 

N intendo's introduction of the virtual Boy met with skepticism from many in the 
game development community, who are uncertain about the success potential of a 
three-dimensional game platform that can only display two colors— red and black. 

One major problem with E3 was the inability to hear anything— the companies turned 
up the sound on their demos in an unbelievable "stereo war." To quote one game 
developer, "I knew we were in trouble when I was nearly run over by the high school 
marching band because I couldn't hearthem!" 

Windows 95 on August 24... M icrosoft, fighting rumors that Windows 95 
might turn into Windows 96, has named August 24 as the date the long anticipated 
software will ship to retail stores. Secret documents leaked to this column via the 
Internet indicate that M icrosoft may plan to achieve this 1995 ship date by buying the 
current year, renaming it "Year M " and postponing the year 1995 until next year. 

Got gossip? E-mailThe Gossip Lady at 71501.3553@compuserve.com. 
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and manufacturers of products popular 
with female teens, including Sassaby Cos- 
metics, Sam & Libby shoes, and Limited 
II clothing stores. Packaged with the 
game will be a music CD and a special title 
called "Sure She Can," featureing the sto- 
ries of teen women around the country 
who have made a difference. 

The Most Important Person 

GirlGamesin H ouston, Texas, is taking a 
different approach to reaching female teens: 
"Being You," the company's first title, is 
geared to young women 14 and older and 
will focus less on finding a guy and more on 
finding yourself. Subtitled 'TheCD-ROM 
for girls to learn more about who they are 
and who they can be." It will explore their 
interests and goals using hundreds of activi- 
ties based on personality profile tests Play- 
ers will download new content quarterly 
from an online service and have access to a 
resource list of organizations covering a 
wide range of subjects— from astrophysics 
to ceramics— that young women can con- 
tact for more information. 

G irIG ames president L aura G roppe 
feels the key to this market isn't a specific 
genre or hook, but titles that put power 
into the users hands. "Our player will get 
to the next quiz or activity because of deci- 
sions she has actively made. She's figuring 
out what makes her tick, and that is very 
empowering." G roppe is keeping quiet 
about who the game's publisher will be and 
any other details about the product, but 
you can bet boy chasing won't be part of it. 
"G iris are approaching the 21st century 
without a lot of guidance, and technology 
is going to permeate their lives from every 
angle," says G roppe. "W e want to equip 
them with thetoolsthey need." 

W hether the squeaky clean hijinks 
featured in M cKenzieand Co. or the per- 
sonal explorations featured in Being You 
will succeed or fail is yet to be seen. Both 
F lanigan and G roppe say they are devoted 
to sticking with this market regardless: 
"W e're in this for the long haul," says 
F lanigan. ■ 

N icole Claro is managing editor for 
Game Developer. 

Barbara H anscome is managing editor 
for Software D evelopment. 
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perspective texture 
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wrong. In Port III of 
this ongoing series, 
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endpoints ond 
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By the time you read this arti- 
cle, the Electronic Entertain- 
ment Expo (E3) will be long 
over, but in the time warp of 
magazine article submission 
deadlines it was just last week- 
end in Los Angeles. E3 is the 
game industry's attempt to 
break from the huge toaster, car 
stereo, and microwave oven event 
that is the C onsumer E lectronics 
Show. W hether this breakaway was 
successful remains to be seen, but one 
thing is certain: the new generation of 
video game consoles garnered a lot of 
attention and floorspace. Atari, 
Sega, 3DO, and Sony battled for 
developers' attention, each hoping to 
wow people with its machine's high 
end features and get the really cool games 
developed for its platform— thejaguar, 
the Saturn, the M ultiplayer, and the 
PlayStation, respectively. 

T he reason I bring this to your 
attention is the one feature advertised 
above all others for each machine is— you 
guessed it— texture mapping. Each com- 
pany claims its system has the most realis- 
tic texture mapping, or the fastest texture 
mapping, or the least expensive texture 
mapping. 

I 'II mention one important 
caveat before I lay into this generation 
of hardware with technical criticism. It's 
completely unclear what relation, if any, 
exists between texture mapping quality 
and overall game quality (and certainly 
sales). Super M ario Bros., for example, 
has absolutely no texture mapping, but it 
sure is a great game, both from a payabil- 
ity and profitability standpoint. 

Keeping that in mind, the texture 



i ( 



c 



II c 



mapping on these machines sure does 
suck. 

H ow do they screw up texture map- 
ping? Let me count the ways. First and 
most noticeable is that all the texture 
mapping hardware in this generation is 
affine. Affine texture mapping, as we dis- 
cussed in "Perspective Texture M ap- 
ping Part I: Foundations" (Under 
the H ood, April/M ay 1995), 
assumes the equation to map screen 
coordinates to texture coordinates is 
linear. This results in really nasty texture 
warping when the linear equation and the 
true equation start to differ by a sub- 
stantial amount. The ironic part 
about affine texture mapping is these 
two equations differ most when the 
textures are very close to your view- 
point, which makes the problem easy to 
spot. 

You can clearly see this for 
yourself in almost every game pro- 
duced for these machines. C heck out 
the floors in some of the fighting 
games or the walls in walkthrough or dri- 
ving games. G et real close and prepare for 
a stomach-churning texture dance. 

Second, and particularly germane 
to today's discussion, some of these 
machines only support integer-tex- 
ture coordinates, that is, the vertices 
of the polygons can only correspond 
to integer coordinates in the source 
bitmap. This wouldn't seem so bad until 
you realize one of the ways to combat the 
affine problems I Ve mentioned is to sub- 
divide your polygons until the linear 
equation is a closer fit (we'll cover this 
technique in the near future). T he subdi- 
vision points are not likely to fall on inte- 
ger texture coordinates, so this hardware 
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forces you to snap to the nearest integer, 
resulting in jitter that's plainly visible in 
the games. 

Finally, a few of the machines only 
support integer screen-space polygon ver- 
tices. In other words, if your polygon 
comes out of your three-dimensional 
transform pipeline with noninteger end- 
points (as it's very likely to do) you've got 
to snap the vertex to an integer pixel loca- 
tion, which causes even more jitter. Con- 
veniently for the purposes of this article, 
this is the exact jitter problem we intro- 
duced into our own texture mapper when 
we converted from floating-point to inte- 
ger rasterization ("Perspective Texture 
M apping, Part II: Rasterization," Behind 
the Screen, J une/J uly 1995). f course, we 
haven't spent millions of dollars on devel- 



Figure 1. Equations 1 Through 3 



X int 

a 
b 

a _ 

b " 



oping a piece of hardware and marketing 
it, so we can fix our jitter problem pretty 
easily. 

J itter Bug 

W e don't have the space to do a total 
review of the work we covered in my first 
two columns on texture mapping. H ow- 
ever, the five-second summary is as fol- 
lows. I n the first column, we derived the 
perspective texture mapping equations, 
including the equations for perspective 
projection and those for stepping the tex- 
ture coordinates across the destination 
polygon (these step values are called the 
gradients). W e also looked at how to cor- 
rectly sample with subpixel accuracy. 
This last topic caused us to investigate 
how to get rid of the cost of this subpixel 
accuracy while retaining its advantages, 
and in the second column we showed 
how to do this using a digital differential 



analyzer (D DA). W e converted our orig- 
inal floating-point rasterizer to an integer 
D D A to realize the savings, but we 
uncovered a nasty jitter as our polygon 
moved and animated. 

This jitter was introduced because 
our triangle gradients are calculated from 
the endpoints of the triangle, and those 
endpoints, when restricted to be integers, 
change by a relatively large amount from 
frame to frame. (The mathematically 
inclined among you will notice that the 
gradients are calculated from two times 
the signed area of the triangle [which is 
also the cross product]. W hen the end- 
points are truncated to integers this area 
changes, altering our gradients and caus- 
ing the jitter.) 

W hat we need is better precision on 



(2) 



the endpoints, but we want to keep the 
advantages of using a D DA rasterizer. 
E nter fractional endpoints. 

Fractional Endpoints 

When I say fractional endpoints, the 
first thing that comes to mind is fixed- 
point math. W hile we are going to be 
using fixed- point numbers to represent 
our vertices and to give us the extra pre- 
cision we need to avoid the integer jitter, 
you'll see we're not going to be rasteriz- 
ing the edges using the familiar fixed- 
point increments. As usual, to pack all 
the information we need into this article, 



Figure 2. Equation 4 



I 'm not going to be able to describe the 
basics of fixed-point math. For a 
description of fixed-point math that's 
easy to understand, I suggest reading 
M ichael A brash's Zen of Graphics Pro- 
gramming (Coriolis G roup, 1994) or the 
PC Game Programmer's E ncyclopedia ± 
which is a neat freeware programming 
book available via ftp on x2ftp.oulu.fi. 

We'll use 28.4 fixed point for our 
endpoints. I'm going to use the integer- 
dot-fraction notation for fixed-point 
numbers, so 28.4 means we have 28 bits of 
(usually signed) integer and four bits of 
fractional precision. 

We'll use this format for two rea- 
sons. First, four fractional bits is enough 
to eliminate the jitter. Second, I happen 
to know that the W indows N T polygon 
rasterizer can be set up to do correct top- 
left 28.4 rasterization, and it always 
helps to have a proven version against 
which to test (although I won't show it 
here, we can write a program that raster- 
izes a polygon with our code, then ras- 
terizes the polygon with W indows N T 's 
rasterizer, so we can check for differ- 
ences to test our rasterizer). Once you 
see how the math works you'll be able to 
derive a rasterizer for whatever fixed- 
point format you like best. 

As I hinted before, instead of using a 
fixed- point or floating-point incremental 
step to move from one scanline to the 
next, as our first rasterizer did, this raster- 
izer will use an error-term DDA (much 
like the Bresenham line-drawing algo- 
rithm, covered in most graphics books). 
H owever, unlike most DDA rasterizers 
you've probably seen, our DDA parame- 
ters will be initialized with fixed-point 
numbers instead of integers. 

W e'll start by defining exactly what 
we mean by fractional endpoints. From 
here on out, x and y are real numbers, 
not integers, and their values are m/F 
and n/F, respectively. The numbers m 
and n are integers, and F is the scaling 



v int 



F Amy - Amn + Anm - 1 + F An 
FAn 



(4) 



x i x o 



a - 1 +1 



(y- y )+ x 

a-l 
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(1) 
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a modb 
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Listing 1. Changes for Fractional Endpoints (Continued on p. 21) 



factor for whatever fixed- point format 
you're using. For 28.4 fixed-point, F = 
16, for 16.16, F would be 65,536, and so 
on. To convert from the fixed- point val- 
ues to real numbers we divide by the 
scaling factor. You commonly see the 
opposite of this when you multiply a 
floating point number by the scaling fac- 
tor to get its fixedpoint value. H ere are 
some useful equations: 



Ax = Xj - x 

Ay = y x - y 



_ Am _ m 1 -m c 



F F 

_ An _ n x - n 



W ell be reusing some of the formulas we 
derived in the first two columns. Refer to 
Figure 1 for Equations 1 through 3. The 
variables a and b are integers in these 
equations— remember that the mathe- 
matically defined mod operator (used in 
Equation 3) probably behaves slightly dif- 
ferently than the modulus operator in 
your chosen programming language. See 
the FloorDivHod function in Listing 1 for 
the correct implementation and 
"Perspective Texture M apping, Part II : 
Rasterization" for an in-depth discussion. 
Equation 1 shows the real formula for a 
left edge under our fill convention (right 
edges are the same equation minus one). 
L et's rewrite E quation 1 to use fixed 
point: 



X int — 



( Am ^ 



An 



m r 



If we do some basic algebra and use the 
ceiling-to-floor conversion in Equation 2 
(you can move integers into and out of a 
ceiling or floor) on this we get the equa- 
tion pictured in Figure 2. 

N ext we'll introduce the symbol R 
(W hy R? I don't know, mostly because 
I 'm running out of letters in the alpha- 
bet!), set it equal to the numerator so 
things look pretty, and finally use Equa- 
tion 3 (the relationship between a rational 
number and its floor and mod) on the 
R/FAn term inside the floor to give us our 
initial condition: 



typedef long fixed28_4; 

inline fixed28_4 FloatToFixed28_4( float Value ) { 
return Value * 16; 

} 

inline float Fixed28_4ToFloat( fixed28_4 Value ) { 
return Value / 16.0; 

} 

inline fixed28_4 Fixed28_4Mul( fixed28.4 k, fixed28_4 B ) { 

// could make this asm to prevent overflow 
return (A * B) / 16; // 28.4 * 28.4 = 24.8 / 16 = 28.4 

} 

inline long Ceil28_4( fixed28_4 Value ) { 
long ReturnValue; 
long Numerator = Value -1 + 16; 
if (Numerator >= 0) { 

ReturnValue = Numerator/16; 
} else { 

// deal with negative numerators correctly 
ReturnValue = -((-Numerator)/16); 
ReturnValue -= ((-Numerator) '/, 16) ? 1 : 0; 

} 

return ReturnValue; 

} 

struct P0INT3D { 
fixed28_4 X, Y; 
float Z; 
float U, V; 

}; 

inline void Floor0ivHod( long Numerator, long Denominator, long &Floor, 
long Mod ) 

{ 



assert(Denominator > 0); 
if(Numerator >= 0) { 

// positive case, C is okay 

Floor = Numerator / Denominator; 

Hod = Numerator '/, Denominator; 
} else { 

// Numerator is negative, do the right thing 

Floor = -((-Numerator) / Denominator); 

Hod = (-Numerator) '/, Denominator; 

if(Mod) { 

// there is a remainder 
Floor—; Hod = Denominator - Hod; 



// we assume it's positive 



} 



} 



fixed28_4 X0Y1 



float DneOverdX 
float DneOverdV 



pVertices[2].X, 

■ pVertices[2].V); 
pVertices[2].X, 

■ pVertices[2].V); 
X0Y1); 



} 

gradients: gradients ( P0INT3D const *pVertices ) 
{ 

int Counter; 

fixed28_4 X1V0 = Fixed28_4Hul(pVertices[l] J - 
pVertices[0].Y 
Fixed28_4Hul(pVertices[0].X • 
pVertices[l].Y 
1.0 / Fixed28_4ToFloat(XlY0 
-OneOverdX; 
for(Counter = 0;Counter < 3;Counter++) 
{ 

float const OneOverZ = l/pVertices[Counter] .Z; 
a0ne0verZ[Counter] = OneOverZ; 
aUOverZ[Counter] = pVertices[Counter] .U * OneOverZ; 
aVOverZ[Counter] = pVertices[Counter] .V * OneOverZ; 

} 

dOneOverZdX = OneOverdX * (((aOneOverZ[l] - a0ne0verZ[2]) * 
Fixed28_4ToFloat(pVertices[0].Y - pVertices[2] .Y)) - 
((a0ne0verZ[0] - a0ne0verZ[2]) * 
Fixed28_4ToFloat(pVertices[l].Y - pVertices[2].Y))); 
dOneOverZdY = OneOverdY * (((aOneOverZ[l] - a0ne0verZ[2]) * 
Fixed28_4ToFloat(pVertices[0].X - pVertices[2].X)) - 
((a0ne0verZ[0] - a0ne0verZ[2]) * 
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Listing 1. Fractional Endpoints (Continued from p. 20) 
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R mod F An 


FAn_ 




FAn 
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R mod F An 


FAn 




FAn 



(5) 



N otice that we moved the floored R/FAn 
term outside the main floor; we can do 
this because a floored term is an integer by 
the definition of the floor function, and 
you can always move an integer into and 
out of a floor. 

Equation 5 is our initial D DA con- 
dition. If we plug in integer y values and 
do the math correctly, the floored R/FAn 
term will be our initial integer x starting 
location, and the numerator of the mod 
term will be our initial DDA error term. 
Before we plug it into this equation, our 
y should be prestepped to the first scan- 
line according to our fill convention, 
which defines the starting integer y as the 
ceiling of the fractional y. A Iternatively, if 
you're two-dimensionally clipping the 
polygon at rasterization time, you'd make 
y be the first scanline you want to draw 
after clipping. 

To calculate our D DA step variables 
for x to step to x', we plug y = y + 1 into 
E quation 4 and see that our equation 
changes by F Am/ FAn. W e use Equation 3 
to convert this ratio into an integer and a 
fractional part: 

' FAm 



int " 



Mnt 



FAn 

E rrorT erm + 

F Am mod F An 
FAn 
(6) 

Equations 5 and 6 will step us on the inte- 
ger raster grid, but we will step according 
to the fractional edge, so we'll get the extra 
precision. As I've mentioned before, it's 
important to notice that the mod terms are 
always positive, so when our error term 
rolls over our D DA will always step by 1 
(in contrast with some other D DAsyou've 



} 

edge: 



Fixed28_4ToFloat(pVertices [1] . X 

dUOverZdX = OneOverdX * (((aU0verZ[l] - 
Fixed28_4ToFloat(pVertices [0] . V 
((aU0verZ[O] - aU0»erZ[2]) * 
Fixed28_4ToFloat(pVertices [1] . V 

dUOverZdV = OneOverdY * (((aU0verZ[l] - 
Fixed28_4ToFloat(pVertices [0] . X 
((aUOverZ[0] - aU0»erZ[2]) * 
Fixed28_4ToFloat(pVertices [1] . X 

dVOverZdX = OneOverdX * (((aV0verZ[l] - 
Fixed28_4ToFloat(pVertices [0] . V 
((aVOverZ[0] - aV0»erZ[2]) * 
Fixed28_4ToFloat(pVertices [1] . V 

dVOverZdV = OneOverdY * (((aV0verZ[l] - 
Fixed28_4ToFloat(pVertices [0] . X 
((aV0verZ[O] - aV0»erZ[2]) * 
Fixed28_4ToFloat(pVertices [1] . X 



- pVertices[2].X))); 
aU0verZ[2]) * 

- pl/ertices[2].Y)) - 

- pl/ertices[2].Y))); 
aU0verZ[2]) * 

- pVertices[2].X)) - 

- pl/ertices[2].X))); 
aV0verZ[2]) * 

- pl/ertices[2].Y)) - 

- pVertices[2].Y))); 
aV0verZ[2]) * 

- pVertices[2].X)) - 



edge( gradients const ^Gradients, 
int Top, int Bottom ) 



pVertices[2].X))); 
P0INT3D const *pVertices, 



Y = Ceil28_4(pVertices[Top].Y); 

int YEnd = Ceil28_4(pVertices[Bottom] .Y); 

Height = YEnd - Y; 

if (Height) 

{ 

long dN = pVertices [Bottom] .Y - pVertices[Top] .Y; 
long dM = pVertices[Bottom] .X - pVertices [Top]. X; 
long InitialNumerator = dH*16*Y - dH*pVertices[Top] .Y + 

dN*pVertices[Top].X - 1 + dN*16; 
FloorDi»Mod(InitialNumerator,dN*16,X, Error-Term); 
FloorDi»Nod(dN*16,dN*16, XStep, Numerator); 
Denominator = dN*16; 

float YPrestep = Fixed28_4ToFloat(Y*16 - pVertices[Top] .Y) ; 

float XPrestep = Fixed28_4ToFloat(X*16 - pVertices[Top] .X) ; 

OneOverZ = Gradients. aOneOverZ[Top] 

+ YPrestep * Gradients. dOneO»erZdY 
+ XPrestep * Gradients. dOneO»erZdX; 

OneOverZStep = XStep * Gradients. dOneOverZdX 
+ Gradients. dOneO»erZdY; 

OneOverZStepExtra = Gradients. dOneOverZdX; 

UOverZ = Gradients. aUQverZ[Top] 

+ YPrestep * Gradients. dUOverZdY 
+ XPrestep * Gradients. dUOverZdX; 

UO»erZStep = XStep * Gradients. dU0»erZdX 
+ Gradients. dUOverZdY; 

UOverZStepExtra = Gradients. dUOverZdX; 

VOverZ = Gradients. al/QverZ[Top] 

+ YPrestep * Gradients. dVOverZdY 
+ XPrestep * Gradients. dVOi/erZdX; 

VO»erZStep = XStep * Gradients. dVOverZdX 
+ Gradients. dVOverZdY; 

VOverZStepExtra = Gradients. dVOverZdX; 

} 



probably seen where you step by 1 for 
right-going edges and by -1 for left-going 
edges). This slightly odd behavior drops 
out of the math when you do the flooring 
divide and mod correctly, as we discussed 
previously. 

We're still doing the same DDA step 
as in my last column (the step code is 
identical), but the various DDA values are 
determined by the real fractional end- 



points, not by the truncated integers. 
M ore importantly, the gradients are calcu- 
lated with the fractional endpoints, which 
avoids the jitter problems that brought up 
this fractional mess in the first place. 

The results are surprising. Visually, 
you can't tell the difference between our 
original floating-point rasterizer and the 
new fractional endpoint rasterizer— they 
both are completely solid and jitter-free — 
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Figure 3. A Pixel 



N-.5 



N+.5 




and we get all the benefits of doing error- 
term integer D DAs. 

L isting 1 shows the changes to our 
texture mapper to use fractional end- 
points ne thing to watch for is overflow 
in these equations, particularly in the 
numerator of E quation 4. 1 f your polygons 
get really big, and your scaling factor is 
large, you can overflow beyond 32 bits. 
M ost architectures make it possible to 
keep a 64- bit numerator around for the 
divide, so you can usually handle this if the 
need arises. 

Off The Map 

L et me just come out and say it: there's a 
bug in the code from my first column on 
perspective texture mapping. N o, it's not a 
bug in any of the rasterization math or 
implementation we've been poring over 
for the last two issues, and it's subtle 
enough that you'd have to know what you 
were looking for and look pretty hard to 
find it. I n fact, M ichael A brash and I were 
talking about a related issue when we real- 
ized there actually was a bug in the code 
and math. W e even tossed around the 
idea of having a contest to spot the bug, 
but I decided against it because I assumed 
it was so subtle nobody would figure it 
out. Of course, within the next day or so 
Walt Donovan (walt@rendition.com) 
from Rendition Inc. sent me e-mail 



describing the very 
problem! 

T he bug is in 
the only part of the 
code where I didn't 
rigidly define the 
math before I start- 
ed out: the real-to- 
integer source-tex- 
ture coordinate 
mapping. 

As we've seen, 
we have rock-solid 
mathematical 
descriptions of the 
rasterization, the 
subpixel stepping, 
the perspective pro- 
jection, and the 
gradient calcula- 
tions. But when it 
comes time in the 
code to take our real texture coordinates 
for the current pixel center and map 
them into integer-source- texture coordi- 
nates, we simply truncate with no expla- 
nation of whether this is the correct 
thing to do or not. It's not, and we're 
going to figure out why. H ere's the sus- 
pect code from our original DrauScanline 
function (the variables on the right are 
floating point numbers): 

int U = UOverZ * Z; 
int V = VOverZ * Z; 

To understand why this code is 
wrong, we need to understand how the 
mapping from the source to the destina- 
tion (or vice versa) works, and to under- 
stand this, we need to understand the 
lowliest element in the graphics pipeline, 
the pixel. As we hinted in previous issues, 
a pixel isn't a single point as we're used to 
thinking, it's really a box; a small box, but 
a box nonetheless. Like every other box 
(with sides of nonzero length), this one 
covers an area, and we need to take that 
area into account when we texture map 
our polygon. 

Figure 3 shows one complete pixel 
and portions of a couple of its neighbors 
We'll call N our integer pixel coordinate, 
and you can see the edges, or walls, of the 
middle pixel are each a half- pixel away 



from the center. This geometry gives our 
pixel a total area of one, as you'd expect. 
The other pixel centers are exactly one 
unit away on either side. 

As we rasterize our polygon on the 
destination grid, we're very careful to only 
light destination pixels when they're "in," 
according to our precisely defined fill con- 
vention, and we're also very careful to only 
generate source texture coordinates (using 
the truncation code for the time being) 
when we're exactly on a destination pixel 
center. W e're basically projecting the des- 
tination pixel center back into the source 
to figure out the source pixel color with 
which to light the destination pixel. The 
UOverZ * z expression generates this real 
source texture coordinate, and our "map- 
ping rule," such as it is, converts this real 
number into an integer source coordinate 
we can use to look up the texture pixel 
(sometimes called atexel) value. 

Figure 4, which shows the source 
texture and its position on the destination, 
gives us a way of visualizing the problem. 
You can also see each of the source texel 
boundries drawn in the destination for the 
purposes of this illustration. If we were to 
rasterize this destination polygon to tex- 
ture map our source, we'd generate source 
coordinates for each of the destination 
pixel centers. As you can see (with the 
help of the arrow showing one of the des- 
tination pixel centers mapping back into 
the source) those pixel centers rarely, if 
ever, map to the source pixel centers. 

Let's look at how our current trun- 
cation mapping rule affects various source 
coordinates by viewing the pixels in Fig- 
ure 3 as the source texels. I f our perspec- 
tive projection for a given mapping takes 
a destination pixel center and maps it to 
the real point denoted by the A in Figure 
3, our truncation rule maps this to pixel 
N (A's value is greater than N , but less 
than N + 1, so truncation maps it to N ), 
which looks about right. In general, we'd 
like our mapping rule to take the real 
source coordinates and map them to the 
nearest integer pixel center, which means 
any points that fall within the box for a 
given source pixel get mapped to that 
pixel's integer coordinate. 

N ext let's say our projection takes our 
destination pixel center to B in Figure 3. 
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Figure 4. Mapping 




Our truncation generates N - 1 for our 
source coordinate, when N is clearly the 
right answer! Oops. 

I\l ow that you see the bug, let me tell 
you how we figured out it was there in the 
first place. W e were talking about various 
texture mapping one day when M ichael 
asked how I would implement a bit (a 
block transfer, or pixel copy) with my tex- 
ture mapper. I n other words, how would I 
allocate the source- texture coordinates and 
the destination- screen coordinates so that 
the source-to-destination mapping was 
one to one? It seems logical to be able to 
do this, not so much because you'll use the 
texture code when you simply want to bit, 
but because if the math is completely right 
you should be able to get an exact 1:1 
mapping just like all the other arbitrary 
mappings you can get with perspective 
projections. 

I thought about this problem for a 
second, and answered that I'd allocate the 
corner texture coordinates and the desti- 
nation coordinates at the exact same coor- 
dinates on the screen, (-0.5,-0.5) and 
(TextureW idth-0.5,TextureH eight- 0.5). 
(0 ur code only handles triangles so I 'd 
obviously need to call it twice to bit the 
whole source, but the top- left and bot- 
tom-right corners are all I needed to 
describe the destination rectangle.) As 
soon as I said this I realized I hadn't 
bothered to define the mapping rule from 
real source coordinates to integer source 
coordinates. 



Destination 

Figure 5 helps illustrate why I chose 
the coordinates I did. I can't stress enough 
in this discussion that to get the correct 
mappings we need to view pixels as areas, 
not just as points. W ith this in mind, the 
coordinates I gave M ichael are the coordi- 
nates of the inifinitely thin edge that com- 
pletely surrounds our source texture 
bitmap, as you can see in Figure 5. T he 
point (-0.5,-0.5) is the upper left-hand 
corner of the texture (the upper left-hand 
pixel center is at [0,0]), and (9.5,9.5) is the 
lower right-hand corner— the edges total- 
ly enclose the texture pixels. If I had cho- 



Figure 5. Source Texture 



sen integer source coordinates for the cor- 
ners we'd be cutting the edge pixel areas in 
half, which you can see if you take Figure 
5 and draw an imaginary edge through the 
pixel center. 

Similarly, I chose the corresponding 
screen coordinates for the destination. I 
wanted the destination pixel centers to 
map exactly to the source pixel centers, so 
it was necessary to completely enclose the 
destination pixels in the same manner as 
the source pixels 

I realized I needed to define a map- 
ping that took a real texture coordinate 
and mapped it to the closest integer pixel 
center. T his is basically a rounding opera- 
tion, and the function for rounding is: 



r = 

mt 



C +■ 



(7) 



Equation 7 is the familiar rounding rule 
where you add a half and floor the result. I 
looked at what effect this rule would have 
on the texture mapper and it fixes the 
problem with B in Figure 3, that's for sure. 
H owever, implicit in any rounding rule is a 
tie-breaking rule that kicks in when the 
value to be rounded is exactly halfway 
between two integers, like C and D in 
F igure 3. E quation 7 will map C to N +1 
and D to N , so it's pretty clear that this is a 
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top- left rounding rule, meaning if the pixel 
center falls on the top or left edge of the 
pixel it is considered "in," and if it falls on 
the bottom or right edge it is considered 
part of the neighboring pixel. T his is obvi- 
ously very similar to our fill convention. 

At first glance, a top-left rounding 
rule seems to work well with our top- left 
fill convention. It looks like the only way 
for our mapping rule to generate a pixel 
that's out of bounds is for the right or bot- 
tom edge of the texture to fall directly on a 
pixel center in the destination (think about 
shifting our bit destination coordinates 
down and to the right by a half pixel so 
they're on integers in the destination), but 
if the right or bottom edge of the texture 
corresponds to a right or bottom edge of 
the destination polygon we don't draw 
those pixel centers anyway because of our 
fill convention. This beautiful harmony is 
broken when you visualize rotating the 
destination polygon by 180 degrees so that 
its edges still correspond with integer des- 
tination pixel centers, but the left edge of 
the polygon corresponds to the right edge 



of the texture. N ow, if we apply our 
rounding mapping rule we'll start with the 
right edge of the texture (T extureW idth - 
0.5, or 9.5 in Figure 3), add a half, and 
floor, resulting in a texture coordinate off 
the edge of our texture! Are we back 
where we started? 

Same Time, Same Channel 

T he answer to that question is no, but to 
find out how we're going to solve the 
problem you'll have to tune in next time 
because I 'm out of space. I will give you a 
hint, however. Equation 7 is just one 
rounding rule. H ere's another: 



c - 



(8) 



Equation 8 works out to be a bottom- 
right rounding rule, which would have 
avoided the problem mentioned at the end 
of the last paragraph, but would result in a 
similar problem with our original orienta- 
tion! Think about what criteria we have 
for choosing between the two rounding 



rules and join me next issue. 

By the way, our texture mapper is 
doing a form of resampling called point 
sampling. We map the destination pixel 
centers into the source and just take what- 
ever texel in which we land. There are 
other forms of resampling where you take 
the corners of the destination pixel and 
map them back into the source to form a 
quadrilateral, and then filter the resulting 
area into a single pixel color. D igital Image 
Warping (IEEE Computer Society, 1990) 
by George W olberg covers a bunch of 
these resampling techniques. 

Once again I'd like to thank Kirk 
lynyk. H e's the reason I know the W in- 
dows NT 28.4 rasterizer is correct— he 
did the original math. ■ 

Chris H ecker thinks that regardless of 
the outcome of the video game console wars, 
it's unlikely anyone will beat Sega's "sphinc- 
ter" advertisement for pure comedy value 
D iscussion of various body parts and their 
relationship to video games is available at 
ched<er@bix.com. 
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Building 
Brains into 
Your Games 



Figure 1. The Layout of Mode 13h 



Column 
Column 1 



memory address (hex) 
A000: 0000 
A000: 0140 



A000: F8C0 




Length of video buffer = 320 • 200 = 64,000 bytes 

Game developers have always 
pushed the limits of the hard- 
ware when it comes to graphics 
and sound, but I think we all 
agree that when it's time to 
implement artificial intelligence 
for a game, A I always gets the 
short end of the stick! In this 
article, we are going to study a potpourri 
of A I topics ranging from the simple to 
the complex. 

A long the way, we are going to try 
out a few demos that use a very rudi- 
mentary graphics interface to illustrate 
some of the simpler concepts. H owever, 
most of our discussion will be quasi-the- 
oretical and abstract. This is because A I 
is not as simple as an algorithm, a data 
structure, or similar things. Artificial 
intelligence is a fluid concept that must 



Row 199 



be shaped by the game it is to be used 
on. G ranted, you may use the same fun- 
damental techniques on myriad games, 
but the form and implementation may 
be radically different. 

Let's begin our discussion with some 
simple statements that define what A I is 
in the context of games. A rtificial intelli- 
gence in the arena of computer games 
implies that the computer-controlled 
opponents and game objects seem to 
show some kind of cognitive process 
when taking actions or reacting to the 
player's actions. These actions may be 
implemented in a million different ways, 
but the bottom line, from an observers 
point of view, is that they seem to show 
intelligence. 

This brings us to the fundamental 
definition of intelligence. For our pur- 
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// GMOD.H graphics module for demos 

unsigned char far *video_buffer = (unsigned char far *)0xA0000000L; 

void Plot_Pixel(int x.int y.int color) 
{ 

// plots the pixel in the desired color a little quicker using binary shifting 
// to accomplish the multiplications 

video_buffer[((y«8) + (y«6)) + x] = (unsigned char )color; 

} // end Plot_Pixel 

void Set_Graphics_Hode(int mode) 
{ 

// use the video interrupt lOh and the C interrupt function to set 
// the video mode 

union REGS inregs.outregs; 

inregs.h.ah = 0; // set video mode sub-function 

inregs.h.al = (unsigned char)mode; // video mode to change to 
int86(0xl0, Mnregs, Jioutregs); 

} // end Set_Graphics_Hode 

void Time_Delay(int clicks) 
{ 

// this function uses the internal timer to wait a specified number of "clicks" 
// the actual amount of real time is the number of clicks * (time per click) 
// usually the time per click is set to 1/lSth of a second or 55ms 

long far *clock = (long far *)0x0000046CL, // address of timer 
start.time; // starting time 

// get current time 
start.time = *clock; 

// when the current time minus the starting time >= the requested delay then 
// the function can exit 

while(labs(*clock - start.time) < (long)clicks){} 
} // end Time_Delay 



Andre LaMothe 

Any element p add 
to a gome to moke it 
more realistic 
con only enhance il. 
Artificial intelligence is 
the next wove to moke 
your gome think and 
respond like o living, 
breathing, [shooting] 
opponent. 
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Figure 2. Tracking the Player 




poses, intelligence is simply the ability to 
survive and perform tasks in an environ- 
ment. The tasks may be to hunt down 
and destroy the player, find food, navi- 
gate an asteroid field, or whatever. Nev- 
ertheless, this will be our loose definition 
of intelligence. 

Now that we have an idea of what 
we are trying to accomplish, where on 
earth should we begin? W e will begin by 
using humans as our models of intelli- 
gence because they seem to be reasonably 
intelligent for carbon units. If we observe 
a human in an environment, we can 
extrapolate a few key behaviors of intelli- 
gence that we can model using fairly sim- 
ple computer algorithms and techniques. 

These behaviors are blind reflexes, 
random selection, use of known patterns, 
environmental analysis, memory-based 
selections and sequential behaviors that 
may encompass some or all of the other 
behaviors. W ell take a look at all of these 
behaviors and explore how we might 
implement them in a computer game, but 
first let's talk about the graphics module 
we are going to use for some of the 
demos. 

The Graphics Module 

H alf the world uses M icrosoft C and C ++ 
compilers and the other half uses Borland 
C and C ++ compilers— so it's always a 
problem publishing demos that depend on 
the use of either. H ence, we are going to 
write C code that is totally compiler inde- 
pendent, based on a graphics interface that 



we are going to write ourselves, and that 
will work on both compilers. The graphics 
interface will be based on graphics mode 
13h, which is 320 by 200 pixels with 256 
colors as shown in Figure 1. For the sim- 
ple demos we are going to write, all we 
want to do is place the VGA/SVGA card 
in mode 13h and plot single pixels on the 
screen. T hus we need two functions: 

Set_Video_Mode(int mode); 

and 

Plot_Pixel(int x, int y, unsigned 
char color); 

W e will use the video bios function 
lOh to set the video mode, but how can 
we plot pixels? Plotting pixels in mode 
13h is very simple because the graphics 
are fully memory mapped. Basically, 
mode 13h is a totally linear array of mem- 
ory that represents each pixel with a sin- 
gle byte. Further, this video memory 
starts at location A000:0000. Figure 1 
shows that there are 200 rows and 320 
columns. Therefore, to compute the 
address of any pixel at (x,y) we simply 
multiply the Y component by 320 and 
add the X. Or in other words: 

memory offset = y*320+x; 

Adding this memory offset to 
A000 : 0000 gives us the final memory loca- 
tion to access the desired screen pixel. 



H ence, if we alias a far pointer to the 
video memory I ike this: 

unsigned char far* video.buffer = 
(unsigned char far*)A0000000L; 

T hen we can access the video mem- 
ory using a syntax like: 

video_buffer[y*320+x] = color; 

And that's it. So, using that information, 
we can then write a simple pixel-plotting 
function and graphics-mode function. 
These two functions should be added to 
each demo so that the demos can perform 
the graphics- related functions without 
help from the compiler-dependent graph- 
ics library. W e're also going to add a little 
time-delay function based on the PC's 
internal timer. The function is called 
Time_Delay() and takes a single parameter, 
which is the number of clicks to wait for. 
L isting 1 shows the complete graphics 
interface named G M D .H for the 
demos contained within this article. Sim- 
ply include the code of the graphics mod- 
ule with each demo and everything 
should work fine. N ow that we have the 
software we need to do graphics, let's 
begin our discussion of A I . 

Deterministic Algorithms 

D eterministic algorithms are the simplest 
of the A I techniques used in games. 
T hese algorithms use a set of variables as 
the input and then use some simple rules 
to drive the computer- control led enemies 
or game objects based on these inputs. 
W e can think of deterministic algorithms 
as reflexes or very low-level instincts. 
A ctivated by some set of conditions in the 
environment, the algorithms then per- 
form the desired behavior relentlessly 
without concern for the outcome, the 
past, or future events. 

The chase algorithm is a classic 
example of a deterministic algorithm. T he 
chase algorithm is basically a method of 
intelligence used to hunt down the player 
or some other object of interest in a game 
by applying the spatial coordinates of the 
computer- control led object and the object 
to be tracked. Figure 2 illustrates a good 
example of this. It depicts a top view of a 
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Listing 2. A Demo of Deterministic Logic 



// Deterministic chasing algorithm demo 
// use numeric keypad to move player 

((include <io.h> 

((include <conio.h> 

((include <stdio.h> 

((include <stdlib.h> 

((include <dos.h> 

((include <bios.h> 

((include <math.h> 

((include <string.h> 



((include "gmod.h" // include our graphics 
module 



II V 
if ( 



typical battleground, on which three 
computer-controlled bad guys and one 
player are fighting. The question is, how 
can we make the computer-controlled 
bad guys track and move toward the play- 
er? ne way is to use the coordinates of 
the bad guys and the coordinates of the 
player as inputs into a deterministic algo- 
rithm that outputs direction changes or 
direction vectors for the bad guys in real 
time. 

Let's use bad guy one as the exam- 
ple. W e see that he is located at coordi- 
nates (bxl.byl) and the player is located 
at coordinates (px,py). Therefore, a sim- 
ple algorithm to make the bad guy move 
toward the player would be: 

// process x-coords 
if (px>bxl) 

bxl++; 
else 

if (px<bxl) 

bxl— ; 
// process y-coords 
if (py>byl) 

byl++; 
else 

if (py<byl) 
byl~; 

T hat's all there is to it. I f we wanted 
to reverse the logic and make the bad guy 
run then the conditional logic could be 
inverted or the outcome increment opera- 
tors could be inverted. As an example of 
deterministic logic, Listing 2 is a com- 
plete program that will make a little com- 
puter-controlled dot chase a player-con- 
trolled dot. Use the numeric keypad to 
control your player and press E SC to exit 
the program. 

N ow let's move on to another typical 
behavior, which we can categorize as ran- 
dom logic. 

Random Logic 

Sometimes an intelligent creature exhibits 
almost random behaviors. These random 
behaviors may be the result of any one of 
a number of internal processes, but there 
are two main ones that we should touch 
upon— lack of information and desired 
randomness. 

The first premise is an obvious one. 



int main (void) 
{ 

int px=160, // starting position of 
player 
py=100, 

bx=0, // starting position of 
bad guy 
by=0, 

done=0; // exit flag 

// set the video mode to 13h 
Set_Graphics_Mode(0xl3) ; 

// main event loop 
while(ldone) 
{ 

// perform player logic 

// get input from keyboard 
if (kbhitQ) 

// which way is player moving? 
switch(getchO) 
{ 

case '8': // up 
{ 

if ((py-=2)<0) 
py+=200; 

} break; 

case '2': // down 
{ 

if ((py+=2)>=200) 
py-=200; 

} break; 

case '6': // right 
{ 

if ((px+=2)>=320) 
px-=320; 

} break; 

case '4': // left 
{ 

if ((px-=2)<0) 
px+=320; 



} break; 

case 27: // exit 
{ 

done=l; 
} break; 

} // end switch 

// end if 

:rform bad guy logic 
x>bx) 
bx++; 

else 

if (px<bx) 
bx— ; 

if (py>by) 
by++; 

else 

if (py<by) 
by--; 

// draw player and bad guy 

Plot_Pixel(bx,by,12); 

Plot_Pixel(px,py,9); 

// wait a bit 
TimeJ)elay(l); 

} // end main while 

// reset graphics back to text 
Set_Graphics_Mode(0x03) ; 

// return success to DOS 
return(O); 

} // end main 



M any times an intelligent creature does 
not have enough information to make a 
decision or may not have any information 
at all. The creature then simply does the 
best it can, which is to select a random 
behavior in hopes that it might be the 
correct one for the situation. For example, 
let's say you were dropped into a dungeon 
and presented with four identical doors. 
Knowing that all but one meant certain 
death, you would simply have to random- 
ly select one! 

T he second premise that brings on a 
random selection is intentional. For 
example, say you are a spy trying to make 
a getaway after acquiring some secret doc- 
uments (this happens to me all the time). 
Now, imagine you have been seen, and 



GAMEDEVELOPER - AUGUST/SEPTEMBER 1995 29 



NTRODUCTION TO D 



Listing 3. A Bunch of Dumb Flies 



// Random logic demo 

// moves a flock of flies around 

// hit any key to exit 



((include <io.h> 
((include <conio.h> 
((include <stdio.h> 
((include <stdlib.h> 
((include <dos.h> 
((include <bios.h> 
((include <math.h> 
((include <string.h> 

((include "gmod.h" // include our graphics 
module 

((define NUH_FLIES 64 // start off with 64 
flies 

typedef struct fly.typ 
{ 

int x,y; // position of fly 

} fly; 

int main(void) 
{ 

fly flys[NUI"LFLIES]; // the array of flies 

int index; // looping variable 

// set the video mode to 13h 
Set_Graphics_Bode(0xl3) ; 

// initialize all flies to random position 
for (index=0; index<NUM_FLIES; index++) 
{ 

flys[index].x = rand()7,320; 
flys[index].y = rand()7,20O; 
} // end for index 

// main event loop 
while(!kbhit()) 
{ 

// erase flies 

for (index=0; index<NUM_FLIES; 
index++) 

Plot_Pixel(f ly s [index] . x , flys [index] . y , 0) ; 

// perform fly logic, translate 
each fly +-2 pixels 

for (index=0; index<NUM_FLIES; 
index++) 

{ 

flys [index] . x+=(-2+rand()7,5) ; 
flys[index].y+=(-2+rand()7,5); 
} // end for index 

// draw flies 

for (index=0; index<NUM_FLIES; 
index++) 

Plot_Pixel(f ly s [index] . x , flys [index] . y , 10) 



// wait a bit 



Time_Delay(2); 

} // end main while 

// reset graphics back to text 
Set_Graphics_Mode(0x03) ; 

// return success to DOS 
return(O); 

} // end main 



the bad guys start shooting at you! If you 
run in a straight line, chances are you are 
going to get shot. H owever, if during 
your escape you make many random 
direction changes and zigzag a bit, you 
will get away every time! 

W hat we learn from that example is 
that many times random logic and selec- 
tions are good because it makes it harder 
for the player to determine what the bad 
guys are going to do next, and it's a good 
way to help the bad guys make a selection 
when there isn't enough information to 
use a deterministic algorithm. M otion 
control is a typical place to apply random 
logic in bad-guy Al. You can use a ran- 
dom number or probability to select a 
new direction for the bad guy as a func- 
tion of time. Let's envision a multiplayer 
game with a single, computer-controlled 
bad guy surrounded by four human play- 
ers. T his is a great place to apply random 
motion, using the following logic: 

// select a random translation 

for X axis 
bxl = bxl + rand()'/.ll - 5; 
// select a random translation 

for Y axis 
byl = byl + randQ'/.ll - 5; 

T he position of the bad guy is trans- 
lated by a random amount in both X and 
Y, which in this case is 4-5 pixels or units. 

Of course, we can use random logic 
for a lot of other things besides direction 
changes. Starting positions, power levels, 
and probability of firing weapons are all 
good places to apply random logic. It's 
definitely a good technique that adds a bit 
of unpredictability to game Al. Listing 3 



is a demo of random logic used to control 
motion. T he demo creates an array of flies 
and uses random logic to move them 
around. Press ESC to exit the demo. 
N ow let's talk about patterns. 

Encoded List Processing 

M any intelligent creatures have prere- 
corded patterns or lists of behaviors that 
they have either learned from experience 
or are instinctive. W e can think of a pat- 
tern as a sequence of steps we perform to 
accomplish a task. G ranted, this sequence 
may be interrupted if something happens 
during the sequence that needs attention. 
But in general, if we forget about inter- 
ruptions then we can think of patterns as 
a list of encoded instructions that an 
intelligent creature consumes to accom- 
plish some task. 

For example, when you drive to 
work, school, or your girlfriend's or 
boyfriend's house, you are following a 
pattern. You get into your car, start it, 
drive to the destination, stop the car, turn 
it off, get out, and finally do whatever it is 
you're going to do. This is a pattern of 
behavior. Although during the entire 
experience a billion things may have gone 
through your head, the observed behavior 
was actually very simple. H ence, patterns 
are a good way to implement seemingly 
complex thought processes in game Al. 
In fact, many games today still use pat- 
terns for much of the game logic. 

So how can we implement patterns 
for game A I ? Simply by using an input 
array to a list processor. T he output of the 
processor is the control of a game object 
or bad guy. I n this case, the encoded list 
has the following set of valid instructions: 

• Turn right 

• Turn left 

• M ove forward 

• Move backward 

• Sit still 

• Fire weapon. 

Even though we only have six selec- 
tions, we can construct quite a few pat- 
terns with a short input list of 16 ele- 
ments as in the example. I n fact there are 
6 16 different possible patterns or roughly 
2.8 trillion different behaviors. I think 
that's enough to make something look 
intelligent! So how can we use encoded 
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lists and patterns in a game for the A I ? 
One solid way is to use them to control 
the motion of a bad guy or game object. 
For example, a deterministic algorithm 
might decide it's time to make a bad guy 
perform some complex motion that 
would be difficult if we used standard 
conditional logic. T hus, we could use that 
pattern, which simply reads an encoded 
list directing the bad guy to make some 
tricky moves. For example, we might have 
a simple algorithm like this: 

int move_x[16] = {-2,0,0,0,3,3,2,1,0, 

-2, -2,-,0, 1,2,3,4}; 
int move_y[16] = {0,0,0,1,1,1,0,0,-1,-1, 

2,3,4,0,0.-1}; 
// encoded pattern logic for a 

16 element list 
for (index=0; index<16; index++) 
{ 

bxl+=move_x [index]; 
byl+=move_y [index]; 
} // end for index 

You'll notice that the encoded pat- 
tern is made up simply of X and Y trans- 
lations. The pattern could just as well 
have contained complex records with a 
multitude of data fields. I 've written 
detailed code that will create an example 
of patterns and list processing, a demo of 
an ant that can process one of four pat- 
terns selected by the keys 1-4. Unfortu- 
nately, it's too long to print here. Go to 
the G ame D ev eloper ftp site, though 
(ftp://ftp.mfi.com/gdmag/src), and you 
can download it there. 

N ow we're starting to get some- 
where, but we need an overall control unit 
with some form of memory, and we must 
select the appropriate types of behaviors. 

Finite State Machines 

Finite state machines, or FSM s, are 
abstract models that can be implemented 
either in hardware or software. FSM s are 
not really machines in the mechanical 
sense of the word, but rather abstract 
models with a set of "states" that can be 
traversed. W ithin these states, the FSM 
not only has a special set of outputs but 
remembers the state and can transition to 
another state, if and only if a set of inputs 
or premises are met. Figure 3 is a typical 



Figure 3. A Typical State Diagram 




Listing 4. The Core FSM Logic for Figure 7 



typedef unsigned short DISTANCE; 

const DISTANCE Tracking.Threshold = 50; 

const DISTANCE Random.Threshold = 100; 

DISTANCE theDistance; 

//Define states and initialize 

enum states{new, random, track, pattern}; 

states currentState = new; 

//FSM loop 

for(;;){ 

switch (currentStateH 
case new: 

//Note: Suitchbox only, causes no behavior 
theDistance = CalcDistanceToPlayerQ; 
if (theDistance > Random_Threshold){ 
currentState = random; 

}else{ 

if (theDistance > Tracking_Threshold){ 
currentState = pattern; 

}else{ 

currentState = track; 

} 

} 

break; 
case track: 

DoTrackBehaviorO; 

currentState = new; 

break; 
case pattern: 

DoPatternBehaviorO; 

currentState = new; 

break; 
case random: 

DoRandomBehaviorQ; 

currentState = new; 

break; 
case default: 

cerr«"state machine has entered an unknown 

state\n"; 

assert(FAIL); 

} 

} 
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Figure 4. A Simple FSM for Al 




depiction of a finite state machine. W e 
see that there is a set of states labeled, S , 
S x , S 2 , and S n We also see that there is a 
set of connecting edges or arcs. T hese are 
called transition arcs and are the premises 
that must be met for the FSM to move 
from state to state. Finally, within each 
state is a set of outputs. T hese outputs can 
be anything we wish— from motion con- 
trols for a game's bad guys to hard disk 
commands. 

So how do we model an FSM in 
software and use it to control the game 
Al? Let's begin with the first question. 

We can model an FSM with a single 
variable and a set of logical conditions 
used to make state transitions along with 
the output for each state. For example, 
let's actually build a simple software state 



machine that controls a computer bad guy 
differently based on the bad guy's distance 
to the player. T he state machine will have 
the following four states: 

• StateO: Select new state = STATE JEW 

• State 1: M ove randomly = STATE .RANDOM 

• State2: Track player =STATE.TRACK 

• State 3: U se a pattern =STATE_PATTERN 

T he FSM 's transition diagram is 
shown in Figure 4. We can see that if 
the bad guy is within 50 units of the 
player, then the bad guy moves into 
State 2 and simply attacks. If the bad 
guy is in the range of 51 to 100 units 
from the player, then the bad guy goes 
into State 3 and moves in a pattern. 
Finally, if the bad guy is farther than 100 
units from the player then chances are 
the bad guy can't even see the player (in 
the imaginary computer universe). In 
that case, the bad guy moves into State 
1, which is random motion. 

So how can we implement this sim- 
ple FSM machine? All we need is a vari- 
able to record the current state and some 
conditional logic to perform the state 
transitions and outputs. L isting 4 shows a 
rough algorithm that will do all this. 

N otethat s (the new state) does not 
trigger any behavior on the part of the 
opponent. Rather, it acts as a state 
"switchbox," to which all states (except 
itself) transition. T his allows you to local- 
ize in a single control block all the deci- 
sion making about transitions 



Figure 5. Viewing Cones 



Although this requires two cycles 
through the FSM loop to create one 
behavior, it's well worth it. I n the case of 
a small FSM , the entire loop can stay in 
the cache, and in the case of a large FSM 
loop, the localization of the transition 
logic will more than pay for the perfor- 
mance penalty. If you absolutely refuse to 
double- loop, you can handcraft the tran- 
sitions between states. A finite-state 
machine diagram will vividly illustrate, in 
the form of spaghetti transitions, when 
your transition logic is out of control. 

N ow that we have an overall thought 
controller, that is, an FSM , we should 
discuss simulating sensory excitation in a 
virtual world. 

Environmental Sensing 

One problem that plagues A I game pro- 
gramming is that it can be very unfair— at 
least to the player. The reason for this is 
that the player can only "see" what's on 
the computer screen, whereas the com- 
puter A I system has access to all variables 
and data that the player can't access. 

This brings us to the concept of 
simulated sensory organs for the bad guys 
and game objects. For example, in a 
three-dimensional tank game that takes 
place on a flat plain, the player can only 
see so far based on his or her field of 
view. Further, the player can't see 
through rocks, buildings, and obstacles. 
H owever, because the game logic has 
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access to all the system variables and data 
structures, it is tempting for it to use this 
extra data to help with the A I for the bad 
guys. 

The question is, is this fair to the 
player? W ell, of course not. So how can 
we make sure we supply the A I engine of 
the bad guys and game objects with the 
same information the player has? W e 
must use simulated sensory inputs such as 
vision, hearing, vibration, and the like. 
Figure 5 is an example of one such imagi- 
nary tank game. Notice that each oppo- 
nent and the player has a cone of vision 
associated with it. Both the bad guys and 
the player can only see objects within this 
cone. The player can only see within this 
cone as a function of the 3D graphics 
engine, but the bad guys can only see 
within this cone as a function of their A I 
program. Let's be a little more specific 
about this. 

Since we know that we must be fair 
to the player, what we can do is write a 
simple algorithm that scans the area in 
front of each bad guy and determines if 
the player is within view. This scanning is 
similar to the player viewing the viewport 
or looking out the virtual window. Of 



course, we don't need to perform a full 
three-dimensional scan with ray tracing 
or the like— we can simply make sure the 
player is within the view angle of the bad 
guy in question by using trigonometry of 
any technique we wish. 

Based on the information obtained 
from each bad guy scan, the proper A I 
decision can be made in a more uniform 
and fair manner. Of course, we may 
want to give the computer-controlled A I 
system more advantage than the human 
player to make up for the A I system 
itself being rather primitive when com- 
pared to the 100 billion-cell neural net- 
work it is competing against, but you get 
the idea. 

Finally, we might ask, "Can we per- 
form other kinds of sensing?" Yes. W e 
can create simulated light detectors, 
sound detectors, and so forth. I have been 
experimenting with an underwater game 
engine, and in total darkness the only way 
the enemy creatures can "see" you is to 
listen to your propulsion units. Based on 
the power level of the player's engines the 
game A I determines the sound level that 
the bad guys hear and moves them 
toward the sound source or sources. 



Memory and Learning 

T he final topic we're going to touch upon 
is memory and learning. M emory is easy 
enough to understand, but learning is a 
bit more nebulous. Learning as far as we 
are concerned is the ability to interact in 
an environment in such a way that behav- 
iors that seem to work better than others 
under certain conditions are "memorized" 
and used more often. In essence, learning 
is based on memory of past actions being 
good or bad or whatever. Imagine that we 
have written a fairly complex game com- 
posed of computer-controlled aliens. 
T hese aliens use an FSM -based A I 
engine and environmental sensing. The 
problem isthat one of the resources in the 
game is energion cubes and the player and 
aliens must compete for these cubes. 

As the player is moving around in 
the environment, he or she can create a 
mental map of where energion cubes 
seem to be plentiful, but the alien crea- 
tures have no such ability; they can only 
stand and are at a disadvantage. Can we 
give them a memory and teach them 
where these energion cubes are? Of 
course we can, we are cybergods! 

One such implementation would 



Figure 6. A Memory Map 
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work as follows: W e could use a simple 
data structure that would track the num- 
ber of times an alien found energion in 
each geographical region of the 
game.(Figure 6 illustrates one such mem- 
ory map.) T hen, when an alien was power 
hungry, instead of randomly bouncing 
around, the alien would refer to this 
memory data structure and select the geo- 
graphical region with the highest proba- 
bility of finding energion and set its tra- 
jectory for this region. 

The previous example is a simple 
one, but as we can see, memory and 
learning are actually very easy to imple- 
ment. M oreover, we can make the com- 
puter A I learn much more than where 
energion is. It could learn the most 
common defensive moves of the player 
and use this information against the 
player. 

W ell that's enough for basic A I 
techniques. L et's take a quick look at how 
we can put it all together. 



Figure 7. Our Al Brain 



Building 

Monsters from the Id 

W e have quite a repertoire of computer 
A I tricks at our fingertips, so how should 
we use it all? Basically, when you write a 
game and are implementing the Al, you 
should list the types of behaviors that 
each game object or bad guy needs to 
exhibit. Simple creatures should use 
deterministic logic, randomness, and pat- 
terns. Complex creatures that will interact 
with the player should use an FSM -based 
A I engine. And the main game objects 
that harass and test the player should use 
an FSM and sensory inputs and memory. 
Figure 7 illustrates a final model of the 
most advanced A I engine we can con- 
struct with what we have to work with. 

The Future 

I see A I as the next frontier to explore. 
W ithout a doubt, most game program- 
mers have focused so much on graphics 
that A I hasn't been researched much. T he 




irony is that researchers have been mak- 
ing leaps and bounds in A I research and 
Artificial Life or A- Life. 

I 'm sure you've heard the common 
terms "genetic algorithms" and "neural 
networks." G enetic algorithms are simply 
a method of representing some aspect of a 
computer-based A I model with a set of 
"genes," which can represent whatever we 
wish— aggressiveness, maximum speed, 
maximum vision distance, and so on. 
Then, a population of creatures is gener- 
ated using an algorithm that adds a little 
randomness in each of the output crea- 
tures' genes. 

Our game world is then populated 
with these gene- based creatures. As the 
creatures interact in the environment, 
they are killed, survive, and are reborn. 
The biological analog comes into play 
during the rebirthing phase. E ither man- 
ually or by some other means, the com- 
puter A I engine "mates" various pairs of 
creatures and mixes their genes. The 
resulting offspring then survive another 
generation and the process continues. 
This causes the creatures to evolve so 
that they are most adapted for the given 
environment. 

N eural networks, on the other hand, 
are computer abstractions of a collection 
of brain cells that have firing thresholds. 
You can enhance or diminish these 
thresholds and the connections between 
cells. By "teaching" a neural network or 
strengthening and weakening these con- 
nections, the neural net can learn some- 
thing. So we can use these nets to help 
make decisions and even come up with 
new methods. 
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ough the roots 
of multiuser dun- 
geons (M U D s) 
go back to games 
like Zork and 
Adventure, Roy 
Trubshaw and 
Richard Bartle 
created the first true M U D in 1979. As 
the I nternet grew, becoming more acces- 
sible, M UDs made themselves at home 
on the Internet, evolving into a diverse 
family of multiuser games. 

T he most common type of M U D is 
the combat MUD, where players visit 
unusual and mythic lands alone or in 
groups, searching for creatures to slay 
and quests to solve. In social M UDs, 
people hang out, chatting in the virtual 
pub of their choice. 

Some M UD users, called mudders, 
enjoy recreating their favorite fantasy 
settings, using such authors asJ.R.R. 
Tolkein, Anne M cCaffery, and C.S. 
Lewis as inspiration. For the mudders 
who crave storytelling in their favorite 
fictional setting, there is the dramatic 
roleplay MUD, in which people create 
compelling drama in a kind of interac- 
tive theater where stories can take 
months or years to tell. 

MUDs and Multimedia 

With CD ROM -induced multimedia, 
today's games typically emphasize slick, 
three-dimensional, ray-traced graphics; 
high-quality voice recording; and catchy 
MIDI scores. This media dependence is 
so common, we often forget that the 
most enduring games had little or no 
wow potential— it was gameplay that 
made the classics great. 



Some people may think the popu- 
larity of M U D s is simply due to their 
being multiuser networked applications, 
but that is only part of it— albeit, an 
important part. For students who have 
I nternet access and are perpetually short 
on cash, M UDs are dirt cheap enter- 
tainment. But fiscal hardship alone 
doesn't explain why so many people pass 
up conventional games to romp about 
some virtual world. 

This article covers the implementa- 
tion of TinyM USH , a popular type of 
MUD. D ue to time and space con- 
straints, we will cover functionality 
issues such as the network interface, 
database, and in-game programming. 

The MUD Basics 

Regardless of type, all M UDs have a 
common concept of location (virtual, of 
course) that affects how players commu- 
nicate. This strong concept of location 
affects communications on a M U D . For 
example, to speak aloud to a group using 
the say command, players must be in the 
same room as the group. 

TinyM USH is representative of 
MUD servers leaning toward social 
rather than combat interactions. Tiny- 
MUSH is an open-ended application 
that has no resolution, unlike a combat 
M UD. Though TinyM USH is typically 
used for social hangouts and interactive 
theaters, M USH s provide a suitable 
communications solution for small 
groups of people who wish to communi- 
cate and collaborate online. 

Usually UNIX 

M U D s do not use fancy graphics or 
audio scores, but they do allow multiple 
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players to interact. M UDs need some 
form of interprocess communication so 
players on different machines at separate 
physical locations are able to play 
together. This requirement has made 
networking a core technology in M UD 
development. 

T he need for reliable networking is 
one reason M UDs have gravitated 
toward UNIX-TCP/IP, a popular 
networking protocol, came bundled 
with U N I X . A nother reason is many of 
the T inyM U SH developers are, or 
were, undergraduates in universities 
whereUN IX iswidely available. TC P is 
not the only networking protocol, but 
TinyM USH 's heritage links it to 
UNIX. OnUNIX, the reliable, connec- 
tion-oriented communication protocol 
of choiceisTCP. 

T he developers of T inyM U SH 
wrote the application in their spare time 
as a form of recreation and did not 
design it for portability to every com- 
puter architecture and operating system. 
M aking M USH run on several flavors 
of U N IX and VM S was more than 
enough to occupy the developers. 

The Network Interface 

TCP/IP is really a group of protocols, 
spanning the network and transport lay- 
ers of the Open Systems Interconnec- 
tion model (OSI). Two TCP/IP appli- 
cation program interfaces (APIs) exist 
on UNIX systems— the Berkeley Socket 
interface, the choice for most program- 
mers, and the less popular Transport 
Layer Interface (TLI) developed at Bell 
L abs. T hough T inyM U SH supports 
both APIs, due to space requirements, 
this article covers only the Berkeley 



Socket interface. 

From a player's perspective, a 
TinyM USH server resides on a specific 
machine at a specific port. This port 
address is a 16-bit integer destination 
port number, which is part of the 
TCP/IP header packet, along with a 
source port number and a source, and a 
32-bit destination address. These 
addresses provide communication end- 
points forTCP. 

For historical reasons, TinyM USH 
comes with a default port setting of 
4,201 but uses a value greater than 
5,000. T his minimizes the chance that a 
conflict can occur between an operating 
system port assigned to a miscellaneous 
service and the TinyM USH port num- 
ber. UNIX reserves ports to 1023 for 
privileged operating system processes, so 
selection of a port greater than 1023 is 
mandatory. 

The function make_socket() creates 
a T C P/l P socket on the port for external 
processes to connect to the server. If this 
call fails, the routine exits. T his action is 
critical; MUSH exits on failure of bind(). 
A server that cannot bind a socket can- 
not allow incoming connections. 

T inyM U SH uses a simple method 
to handle communications between the 
TinyM USH server and the players. A 
user connects to a M U D using a client 
like Telnet. Using Telnet, players send 
commands consisting of character 
strings to TinyM USH. TheMUD, 
often called the server, receives and acts 
upon the text. T he M U D processes and 
parses the player's actions, sending the 
results back to the player. 

W hen a player's client program 
connects to a TinyM USH server, the 
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operating system marks the file descrip- 
tor corresponding to the socket as hav- 
ing input pending. During the main 
loop of the server MUSH calls selectQ 
to see if any file descriptors are ready 
for input or output. After selectO 
returns, the M UD services player con- 
nections with pending I/O and handles 
new connections. 

TinyMUSH may disallow or 
restrict connections from specific com- 
puters or entire networks. After the 
acceptO call returns, the server makes 
the connection to the player's client. 
Once connected, the server knows the 
source address of the client. Tiny- 
M USH checks the source address 
against a list of disallowed addresses 
and mask pairs. For example, Tiny- 
MUSH rejects the connection from all 
clients at the host 128. 92. 15. 15 if the 
address pair 128.92.0.0 255.255.0.0 is in 
the reject list. 

After restriction checks for the 
connecting player are made, a DESC 
structure for the player is filled in. The 
DESC includes the file descriptor, host 
information, a player dbref, and doing 
message, among other information. 

T he server sets the file descriptor to 
nonblocking, representing the player's 
socket. A writeQ to a nonblocking file 
descriptor won't result in the server 
waiting, pending completion of the 
input or output operation. TinyM USH 
does not know the state of the player's 
client, so it is possible that the operating 
system's output buffer could otherwise 
fill, blocking the server and hanging the 
game. 

Each DESC has input and output 
queue pointers, allowing fast processing 
of the user's data. The desc stores the 
size of the input and output queues and 
the amount of input and output. 
Because sockets to player's clients may 
block at any time for arbitrary lengths of 
time, the output queues are finite. After 
the player's output queues exceed a 
limit, the server discards further player 
output. 

After the player successfully con- 
nects, TinyMUSH completes and 
returns the desc. N ext, the server dis- 
plays a standard welcome message to the 



user with a brief description of the com- 
mands available. The commands avail- 
able at this point are only those provid- 
ed by the networking code. 

TinyMUSH has a programmable 
interface and it allows objects to run 
many of the same commands as the 
players. But some commands, like 
logout and quit, only make sense for 
connected players. Thus, the network- 
ing code implements and handles these 
commands, bypassing the rest of the 
game. W hen the player connects to the 
game, using either the command con- 
nect or create, all the commands are 
available. 

The complete list of network-level 
commands are: 

• create 

• connect 

• QUIT 

• LOGOUT 

• WHO 

• DOING 

• SESSION 

• OUTPUTPREFIX 

• OUTPUTSUFFIX. 

The commands listed in uppercase 
letters are case sensitive; create and con- 
nect are not. T he capitalized commands 
indicate that commands are executable 
by players over a network connection 
only. 

T he commands create and connect 
are only available to players not yet asso- 
ciated with a player object. Once the 
connection is associated with a player 
object, a flag in the desc structure is set, 
indicating that socket is connected. 
nee the player connects, the create 
and connect commands are no longer 
available. The uppercase network com- 
mands, available through the game, exist 
in a small hash table. 

T he QUIT command disconnects the 
user from the server. LOGOUT is more 
complex; it disassociates a DESC structure 
from a player object and places the user 
back into a logged-out state, as if he or 
she had just connected to the server, who, 
DOING, and SESSION are all variants of one 
command, showing information on con- 
nected players. 

OUTPUTPREFIX and OUTPUTSUFFIX are 
among the less-used commands in 



T inyM U SH . As the output from com- 
mands such as who spans many lines, it is 
difficult to determine where the output 
of a single command begins and ends. 
The outputprefix command takes a 
string as an argument, like: 

OUTPUTPREFIX ThisIsTheStart 

and prints ThisIsTheStart on a separate 
line before the output of every com- 
mand. Programs, called robots, connect 
to M UDs and require an easy way to 
parse the results of their actions, output- 
prefix and outputsuffix are simple ways 
for robots to find the start and end of 
their command output. Robots function 
as mailers, mappers, off-M UD database 
interfaces, and amusing Al simu- 
lacrums. 

After the networking code parses 
the user text into a command buffer, the 
server searches for the text in a hash 
table with the networking commands. 
Should the hash routines not find the 
command, TinyM USH checks the DESC 
structure to see if it is associated with a 
player object. If the DESC indicates a con- 
nected player, the function do.command 
passes the command along to the func- 
tion process_command, as it may be a 
game- related command, like Say Hello. 

If the DESC indicates no commands 
associated with a player object, the serv- 
er assumes it must use either the create 
or connect command. The function 
check_connect() parses the input into 
three parameters. check_connect() then 
checks the first two characters of the 
first parameter of the command for the 
strings co and cr to see if the player 
entered either a connect or create com- 
mand. If not, the server flags the input 
as invalid and shows the user the stan- 
dard welcome message again. 

W hen the server recognizes a con- 
nect command, M USH searches for and 
authenticates the player name password. 
If the player name or password is 
invalid, the server responds with a fail 
message to the user. After three failed 
attempts, the server closes and shuts 
down the user's connection. If the play- 
er's name and password are correct, the 
server checks to see if players are 
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allowed to log in and that the number of 
players connected is less than the maxi- 
mum. If both conditions are true or the 
player is a wizard (a term for a Tiny- 
MUSH administrator), then the 
MUSH allows the user to log in. 

T he user is associated with a player 
object by storing the player object's 
dbref in the DESC structure along with 
the connect time. The player is shown 
the welcome message for new players or 
the message of the day for existing play- 
ers. T he game administrator receives an 
additional message often set by another 
administrator as a note. Should the 
server be refusing logins or have more 
than the maximum number of players 
connected, the player receives a reject 
message. 

Once the player has been connect- 
ed, the server initializes various attribut- 
es on the player, such as the player's last 
site and last connect time. W hen the 
player connects, all objects at the play- 
er's location receive the message: 

<Player> has connected. 

where <Player> is the player's name. 

The final act in connecting a player 
is the queued execution of a set of com- 
mands when the player logs in to the 
game. T hese commands are stored in an 
attribute called aconnect on the player, 
objects in the master room, and the 
master room itself. 

The Command Interface 

Learning TinyM USH is not easy— there 
are more than 200 commands and 150 
functions— but the basics of M U SH are 
not hard. T inyM U SH provides users 
with an interpreted, shell-like language. 
The internal language to TinyM USH , 
often called M USH - code, is both a bane 
and a boon— programming simple 
things is easy, enabling new users to start 
right away; but for complex tasks, 
MUSH -code is tedious. M ost users 
never really learn to program M USH — 
instead, these players, like unsophisticat- 
ed DOS users, stick to a minimal set of 
commands they use often. 

The TinyM USH command inter- 
face is user extensible. Users call player- 



created commands "$ commands" 
because the definition is preceded by a $. 
$ commands appear no different than 
the built-in commands to the user. 
Attributes store the $ commands on 
objects. 

TinyM USH es have the capability 
to provide global $ commands in a mas- 
ter room. When a player-typed com- 
mand matches nothing, the server 
checks the master room and its contents 
for $ commands. TheTiny M USH 
master room enables user-defined global 
commands in the master room to be 
available everywhere on the M U D . 

TinyM USH has exits providing a 
path from one object to another. Players 
use exits like commands, traversing exits 
by typing the name of the exit only. 
Users can lock exits against some or all 
players. W hen anyone tries to traverse a 
locked exit, the server triggers the fail 
action attributes for the exit. An action 
is a set of three attributes: <name>, 
o<name>, and a<name>. For the failure to 
traverse an exit, the action attributes are: 
fail, ofail, and afail. And, in the case 
of players and things, objects trigger the 
fail action when failing to pick up an 
object that is locked. 

A player opens an exit, linking and 
locking it to location #0. L inking an exit 
gives it a destination, and locking is a 
way of restricting who can and cannot 
use the exit. Locking the exit to #0 
means that any object traversing the 
cave exit must either be #0 or carrying 
#0. Because #0 is a room on nearly every 
M USH , neither case is likely. When 
Alaric attempts to traverse the exit, he 
triggers the fail action. All players other 
than Alaric will see the ofail text fol- 
lowing Alaric's name, and only Alaric 
will see the fail message. The server 
executes any commands in the exit's 
afail attribute, so any number of actions 
can happen. 

Executing the 

TinyM USH Commands 

W hen a player types in the command 
say Hello everyone!, the networking 
code buffers the text in the player's desc. 
After the network layer parses the com- 
mand into a distinct command buffer, 



the main loop eventually arrives at the 
code that handles interactive commands. 
The server calls the function do.com- 
mandO with the player's desc and the 
command typed. 

Each player's DESC contains a buffer 
for interactively typed commands, but 
there are noninteractive commands, too. 
T hese commands are triggered by $ 
commands or other nondirect methods, 
like an object programmed to bark like a 
dog whenever anyone enters the room. 
N oninteractive commands take a back 
seat to commands from the sockets, so 
the turnaround time for the players is 
short. All objects take a backseat to 
players, as the server adds commands 
typed by objects to the end of a low-pri- 
ority queue. 

In the old days of TinyM USH , the 
command parser was one huge suitchO 
statement. As the command set grew, 
the organization of the cases became 
unwieldy and inefficient. The develop- 
ers took the next logical next step— a 
hash table was put in place for version 
2.0. 

I n T inyM U SH , there are two com- 
mand hash tables. The first hash table 
contains commands reserved only for 
connected players. The second table 
contains the commands available to 
both players and M USH objects alike. 
Listing 1 shows the in-game command 
hash table. 

When the function do_command() 
receives a player's command, the code 
checks the command to see if it exists in 
the command table for connected play- 
ers. If the command is not in the hash 
table with connected player commands, 
the function do_command() calls 
process_command(). T he handling of play- 
er commands has to be fast. The addi- 
tion of the hash table to TinyM USH 
was a plus, but the developers took 
another shortcut— the recognition of 
single character lead-ins. 

Single character leads are a group 
of characters in a 256- character array, 
where each character is the unique first 
character of a commonly typed com- 
mand or abbreviation of a command. A 
command say has an abbreviation of ", 
used like so: 
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Listing 1. The In-Game Hash Table 



typedef struct cmdentry CHDENT; 
struct cmdentry { 

char *cmdname; 

NAMETAB *switches; 

int perms; 

int extra; 

int callseq; 

void (*handler) (); 

}; 

NAMETAB, defined in htab.h, is a list of switches that modifies the command behavior. Rather 
than sending text to an object, a message could be sent to an object's contents with the use of 
/contents on the Spemit command. 

typedef struct name_table NAMETAB; 
struct name.table { 
char *name; 
int minlen; 
int perm; 
int flag; 

}; 

Example CHDENT entries from command. c: 

For the command, Spemit, which sends text to an object, in the form: 
Spemit <object>=<text>. The command: 

Spemit The Statue=The pigeons are coming! 

Uould send the text, "The pigeons are coming!" to the object named "The Statue." 

{ 

(char *) "@pemit", 
pemit_sw , 

CA_NO_GUEST I CA_NO_SLAVE, 
PEMIT.PEMIT, 
CSJVOJRG I CS.INTERP, 
do.pemit 

}, 

The switches are: 

NAHETAB pemit_sw[] = 

{ 

{(char *) "contents", 1, CA.PUBLIC, PEMIT.CONTENTS}, 

{(char *) "list", 1, CA.PUBLIC, PEBIT.LIST I SW.MULTIPLE}, 

{(char *) "object", 1, CA.PUBLIC, 0}, 

{NULL, 0, 0, 0} 

}; 



"Hello everyone 

You say "Hello everyone!" 

Both say and " exist in the com- 
mand hash table, but only " is a single- 
character lead— s would make a lousy 
single character lead, blocking any user- 
defined commands or other built-in 
commands starting with "s". W hen 
process_command() receives the command 
buffer, the function uses the first char- 
acter of that buffer as an index into the 
array of single-character lead-ins, called 
prefix_cmds[]. T his indexing will quickly 



acquire the pointer to the entry of the 
command in the hash table, that is, if 
the entry in prefix_cmds[] isn't null. If 
the prefix_cmds[] entry is null, the server 
looks up the command in the hash table. 

I f the command typed did not have a 
character lead-in, the server has more 
work to do. It must match the player's text 
against all possibilities Is the player typing 
in a built-in command, like traversing an 
exit, or triggering a $ command? And, if 
the command is an exit or a $ command, 
where are they— on the player, in the 
room, or in the master room? 



If the matching of a lead-in pro- 
duces a NULL, T inyM U SH starts with 
the home command, which deserves some 
special treatment because it instantly 
transports all players home. The game 
checks the home command right after the 
lead-ins because exits, matched before 
commands, could redefine all the move- 
ment commands, allowing the user to be 
trapped. 

To execute the player's command, 
the server must know the type of com- 
mand. Is north an exit, or is it a local 
command on a nearby vehicle to make it 
go north? As exits and $ commands can 
have any name, the server matches com- 
mands to all the various possibilities. 
T he order of command matching is: 

• Reserved commands for connected 
players 

• Common commands with unique 
single-character lead-ins 

• The home command 

• Exits in the same room as the player 

• G lobal exits in the master room 

• Built-in commands (like say) 

• L eave al i ases for objects 

• E nter aliases for objects 

• $ commands on the player 

• $ commands on nearby objects and 
the location 

• $ commands on objects in player's 
inventory 

• $ commands on the master room and 
any objects in the master room. 

Because the game matches $ com- 
mands last, those commands cannot 
redefine anything, but players can use 
exits to redefine built-in commands. 

The function process_command() han- 
dles the matching order of the commands 
after the connected player-only com- 
mands. Once the processing function is 
called, the server will handle each com- 
mand depending on what sort of com- 
mand is entered. The server handles all 
built-in commands with process_cmdent() 
and exits by move_exit(). The $ com- 
mands are first matched in atr_matchl() 
and placed on the low- priority queue for 
execution after the interactive commands. 

Because the M U SH built-insare 
the commands used most often, a look 
into how process_cmdent() handles com- 
mands is worthwhile, especially since 
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the built-ins compose the core function- 
ality of M USH . 

The function process_cmdent() 
provides the sanity checking before 
calling the command handler pointed 
to in the CMDENT type. W hen the hash 
location routine returns a pointer to the 
built-in command table, the entry is of 
the type cmdent. chdent contains a 
detailed description of a command, 
including possible command switches 
that alter the command behavior, per- 
missions for who may invoke the com- 
mand, special flags for the command 
handling function, flags describing the 
arguments, and a pointer to the com- 
mand handling function. A hash table 
of type CMDENT describes all the M USH 
built-in commands. 

Before the server calls the com- 
mand handler function, one last check 
remains: should the command's argu- 
ments be evaluated? Evaluation will 
expand the substitution characters' func- 
tional expressions in a recursive- descent 
fashion. After the server decides 
whether or not to evaluate the argu- 
ments, TinyM USH calls the command 
handler via the function pointer in 
cmdent, handling the player's request. 

The Database Layer 

H ackers treat the database layer of 
TinyM USH with more respect— even 
awe— than any other part of Tiny- 
M U SH . N ew, aspiring T inyM USH 
hackers, called mushhacks, avoid modi- 
fying this section with good reason- 
mess the database up and the best you 
can hope for is that large sections of 
your virtual world will become corrupt- 
ed. A t worst, one wrong move can result 
in the premature end of the MUD, 
mangling the database into a worthless 
pattern of bits. I t's not just the program- 
mer's lost work, either— it is everyone's. 
Database corruption causes many 
human years of player efforts to be lost. 

Dbm makes the TinyM USH data- 
base possible. UNIX usually comes with 
the dbm library, and if dbm is not pre- 
sent, it is replaceable with gdbm, a pub- 
licly available version of dbm by the 
Free Software Foundation. Dbm is able 
to maintain huge numbers of key and 



Listing 2. The MUSH Main Loop Function (Continued on p. 42) 



void 

shovechars(port) 
int port; 

{ 

[...] 

while (mudstate.shutdown_flag == 0) { 
get_tod(8icurrent_time) ; 

last.slice = update_quotas(last_slice, current.time); 

process_commands(); 
if (mudstate.shutdown.flag) 
break; 

/* test for events */ 

dispatchQ ; 

/* any queued robot commands waiting? */ 

timeout. tv_sec = que_next(); 
timeout. tv_usec = 0; 

next.slice = msec_add(last_slice, mudconf .timeslice); 
slice.timeout = timeval_sub(next_slice, current.time) ; 

FD_ZER0(8iinput_set); 
FD_ZER0(8ioutput_set); 

/* Listen for new connections if there are free descriptors */ 

if (ndescriptors < avail_descriptors) { 
FD_SET(sock, 8iinput_set) ; 

} 

/* Bark sockets that we want to test for change in status */ 

DESC_ITER_ALL(d) { 

if ( !d->input_head) 

FD_SET(d->descriptor, Mnput.set); 
if (d->output_head) 

FD_SET(d->desc riptor , &output_set) ; 

} 

/* Wait for something to happen */ 

found = select(maxd, Mnput.set, !ioutput_set, (fd_set *) NULL, !ttimeout); 
if (found < 0) { 

if (errno != EINTR) { 

log_perror("NET", "FAIL", "checking for activity", "select"); 

} 

continue; 

> 

/* if 'found then time for robot commands */ 

if (Ifound) { 

do.topfmudconf . queue.chunk) ; 
continue; 

} else { 

do_top(mudconf .active_q_chunk) ; 

} 

/* Check for new connection requests */ 

check = Checklnput(sock); 
if (check) { 

newd = new_connection(sock); 
if (!newd) { 

check = (errno && (errno != EINTR) U 
(errno != EMFILE) it 
(errno != ENFILE)); 

if (check) { 
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Listing 2. The MUSH Main Loop Function (Continued from p. 41) 



} else { 



log_perror("NET", "FAIL", NULL, "new.connection"); 



} 



if (newd->descriptor >= maxd) 

maxd = newd->descriptor + 1; 



} 



/* Check for activity on user sockets 

/* DESC_SAFEITER_ALL() is a define which steps through the player 
/* descriptors, which contain the sockets. 

*/ 

DESC_SAFEITER_ALL(d, dnext) { 

/* Process input from sockets with pending input */ 

check = CheckInput(d->descriptor); 
if (check) { 

[...] 

/* Process received data */ 

if (!process_input(d)) { 

shutdownsock(d, R.SOCKDTED) ; 
continue; 

} 



/* Process output for sockets with pending output */ 

check = CheckOutput(d->descriptor); 
if (check) { 

if ( !process_output(d)) { 

shutdownsock(d, R.SOCKDTED) ; 

} 

} 



content pairs in a database, accessing a 
keyed item quickly using a hash routine. 

T he database consists of a few files, 
but the main file has the .db suffix. This 
file contains the size, version, the list of 
user-named attributes, and some infor- 
mation for each object. The DB file 
stores the following object data: 

• name 

• location 

• exits 

• contents 

• attributes contained 

• parent 

• lock 

• owner 

• monetary worth 

• status flags. 

Sound familiar? It should— this 
information is stored in the in-memory 
object array of type OBJ. 

The database is simply formatted 



because it's read in sequentially and 
checkpointed at intervals during run 
time. T he part of the database contain- 
ing the attribute data, sometimes called 
the attribute database, is more complex. 
Attribute text may exist anywhere in 
the attribute file, so all reads are ran- 
dom-access. T he attribute database uses 
dbm. The dbm database uses the 
attribute and object numbers combined 
for a key. T he data in the dbm database 
associated with the key is an offset and 
length into the flat file that stores the 
attribute text. 

When an attribute is being refer- 
enced, the server calls atr_get_raw(). 
M USH creates a unique key for the 
attribute and calls FETCHQ. FETCH () is a 
define attribute, referencing the function 
cache_get(). The cache is a transparent 
layer over the database. W hen an object 
is referenced and not present in the 



cache, the object is read in from disk. 

D uring run time, the game employs 
a bitmap of the file storing the attribute 
text, with each bit corresponding to a 
block within the file. T he server uses the 
bitmap to allocate and deallocate space 
from the file. If an attribute being writ- 
ten to the file is larger than any free area 
in the file, TinyM USH calls the func- 
tion grou_bit(). grou_bit() extends the 
database bitmap. Then, the game writes 
the attribute to the end of the file, the 
position in the attribute file, and the 
length of the key into the dbm database. 

Putting It All Together 

T inyM USH, like all C programs, has a 
main() function where execution begins. 
In mainO, the server performs startup 
initializations; it checks to see if a new 
database is to be created, initializes 
memory allocation structures, hash 
tables, reads in the file of configuration 
parameters, loads the database, and calls 
shovecharsO. T he loop in shovecharsO is 
where the game remains until shut- 
down, when the database is written out, 
all file descriptors written to, and the 
server exits. 

L isting 2 shows the main loop of 
TinyM USH; the function shovecharsO 
continues until an administrator types 
fishutdoun, setting the shutdown flag that 
terminates the game. I n this loop, the 
current time is important— players may 
enter only so many commands per time 
slice, and seiectO waits until the end of 
the next time slice or when any network 
activity occurs, whichever comes first. 

Because T inyM U SH bases com- 
mand quotas on time, the server 
acquires the current time in the main 
loop. The server uses command quotas 
to limit the number of interactive com- 
mands one player may execute in a peri- 
od of time, called a time slice. W ith the 
quotas updated to reflect the current 
time, the M USH server executes as 
many commands as users can afford 
with their quotas. 

D uring its execution, T inyM U SH 
must perform regular maintenance tasks 
periodically. The database must be 
checkpointed, disconnected, and float- 
ing rooms identified, idle players boot- 
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ed, garbage objects collected and so on. 
So the main loop of shovecharsO calls 
dispatchQ. The function dispatchO 
checks the time to see if any periodic 
events need to be performed. 

nee the game queues its com- 
mands and miscellaneous events, it waits 
until either network activity occurs (on 
the player sockets), or the current time 
slice expires with the seiectO function. 
I f there is network activity, MUSH typ- 
ically processes no commands from the 
queue of noninteractive commands and 
processes three commands from the 
queue if no network activity exists. As I 
mentioned, the bias to interactive com- 
mands exists to give the players first 
crack at the CPU. 

After seiectO in shovecharsO 
returns, two fd.sets return, informing 
the server which file descriptors have 
input ready and are ready to receive out- 
put. T hese fd.sets enable the network- 
ing code to handle the player connec- 
tions by exception rather than polling. 

At the end of the main loop in 



shovecharsO, the server checks the exis- 
tence of pending input and output on 
the player's sockets. TinyM USH checks 
all the sockets, reading those with input 
and placing commands in a linked list. 
The server now writes to sockets ready 
to receive pending output until they 
block or until MUSH has written all 
pending output to the socket. T hen, the 
loop begins again and repeats until a 
wizard types @shutdoun, ending the game. 

MUDS: 

Nonstop Playgrounds 

M UDs are international activities, run- 
ning for days or weeks at a time. The 
MUSH may stop to make a stable back- 
up or go down with a system crash. But 
other than that, TinyM USH , like most 
M UDs, just keeps looping about, pro- 
cessing commands, allowing virtual 
playgrounds on the I nternet to continue. 

By necessity, we couldn't discuss 
many significant parts of the server, 
including the operation of the in- memory 
database cache, the operation of the com- 



mand queues, the method of argument 
evaluation, and in-game game help sys- 
tems. W e have also included only a small 
sampling of appropriate code listings. To 
access the remainder of my listings, go to 
the Game Developer ftp site at 
ftp://ftp.mfi.com/gdmag/src. T he code to 
TinyM USH is freely available via anony- 
mous ftp at caisr2.caisr.cwru.edu in the 
directory /pub/mush. On the Web, try 
ftp://caisr2.caisr.cwru.edu/pub/mush/. ■ 
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Real-Time 
3D Modeling 



Listing 1. Square.ASC 



Ambient light color: Red=0.3 Green=0.3 Blue=0.3 

Named object: "Flat Square" 
Tri-mesh, Vertices: 8 Faces: 12 
Vertex list: 



X: 1.000000 Y: 1.000000 Z: 1.000000 
X : -1 . 000000 Y : 1 . 000000 Z : 1 . 000000 
X : -1 . 000000 Y : -1 . 000000 Z : 1 . 000000 
X: 1.000000 Y : -1. 000000 Z: 1.000000 



Vertex 
Vertex 1 
Vertex 2 
Vertex 3 
Face list: 

Face 0: A:2 B:l C:0 AB:1 BC:1 CA:1 
Material: "Default" 
Face 1: A:3 B:2 C:0 AB:1 BC:1 CA:1 
Material: "Default 



The hottest new games are immer- 
sive three-dimensional environ- 
ments controlled by the players- 
games known as real-time 3D 
games. I n making this type of 
game, an artist must create the 
three-dimensional models seen 
during gameplay. T his is called 
real-time3D modeling. 

The best way to get a technical 
handle on real-time 3D modeling is if 
you understand its low- level storage 
structure. In this article, we'll explore a 
3D Studio .ASC file line-by-line and 
discuss it in terms of real-time 3D mod- 
eling. After that, we'll see a tutorial that 
will demonstrate one of the lesser- 
known areas of real-time 3D modeling: 
3D sprites. 

How Does it Work? 

The term "real-time 3D modeling" means 
building computer models of anything for 
real-time three-dimensional applications. 
In our case, we specifically mean games. 
The term is really quite specific. Real-time 
means the code computes, on the fly, the 



scene players see while they are playing. 
Descent, Flight Unlimited, Indycar Rac- 
ing, and most virtual reality games are 
examples of real-time 3D games. These 
games contrast with prerendered three- 
dimensional games like M yst or 7th 
Guest. 

Of course, games do exist that 
span this division. For example, Alone 
in the Dark features a real-time three- 
dimensional human model walking 
around in prerendered rooms. If you've 
seen this game, the difference between 
the two types of art is immediately 
obvious. 

Doom is also an example of a real- 
time 3D game— sort of. The characters 
are what I call 3D sprites— a series of small 
bitmaps, which are pictures of a person 
viewed from several angles. Some people 
would not call the graphics used in D oom 
true real-time 3D , which is usually syn- 
onymous with vector-based polygonal 
three-dimensional models. H owever, vec- 
tor models and 3D sprites both represent a 
three-dimensional object in a virtual 
world. Because they are both gross 
approximations of the three-dimensional 
object they represent, I submit them both 
to the skeptical reader as valid forms of 
real-time 3D models. 

It is true that vector models have 
capabilities that 3D sprites do not. For 
example, you can change the shape of a 
vector model in real time. 3D sprites also 
have strengths that polygon models lack, 
so let's accept each as a different way of 
solving the same problem: accurately rep- 
resenting an object in a real-time simulat- 
ed environment. We'll explore 3D sprites 
in detail later on. For now, let's talk about 
vector models. 
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Limitations of 
Real-Time Modeling 

G ame artists beware— real-time modeling 
is very limiting compared to normal three- 
dimensional modeling. If you're working 
in 3D Studio, you can experience the limi- 
tations that real-time modeling imposes, 
only by disabling inherent functions such 
as shadows, reflections, anti-aliasing, and 
all material features except small textures. 
You can use only flat shading and ambient 
lighting, don't use more than 1,000 faces, 
and render to 320- by- 200 pixels only. N o 
problem? T hen you're a real-time 3D 
artist! 

W e real-time 3D artists learn to 
understand the reasons for these limita- 
tions and work with (and around) them. 
The limits are imposed because three- 
dimensional games usually need a frame 
rate between 10 and 30 frames per second 
for smooth motion— at least 20 times 
faster than 3D Studio renders a compara- 
ble scene. Our art will actually be judged 
in another dimension— smoothness. As 
our model gets simpler the frame rate 
improves, and the gameplay gets smoother 
and better. 

If we understand the basics of how 
our models are rendered at run time, we 
can make sure trade-off decisions benefit 
the art in the game. For example, many 
game architects often avoid smooth shad- 
ing in favor of textured, flat shading; how- 
ever, this deserves some thought. 

Untextured smooth shading does 
have strengths. If a model is G ouraud 
shaded, you can very simply model curved 
surfaces without affecting the appearance 
of the model, which frees up faces to be 
used elsewhere. Smooth shading also 
yields excellent results on curved objects of 



a single color, such as a pool cue or car 
body. 

So, there is a tradeoff between the 
detailed surfaces provided by textured, 
flat- shaded faces and the speed and 
smoothness of G ouraud shading. W e 
need both artistic judgment and technical 
knowledge to make the correct decision. 

3D Studio .ASC File 

Let's get technical and explore exactly 
what real-time 3D models are made of. 
To be specific, we'll assume this common 
working situation. An artist supplies a 
simple 3D Studio model to a program- 
mer, who uses it to write or test his or her 
parser program. 

Listing 1 shows SQUARE.ASC, 
which is about the simplest model you can 
make with 3D Studio. It defines a flat 
square composed of four vertices and two 
triangular faces. The first line describes 
the lowest lighting level possible. We'll 
deal with lighting another day; we can 
safely ignore it for now. 

L ine 3 starts the definition of an 
object. 3D Studio, in the simplest case, 
stores its data by organizing objects that 
contain faces and vertices. 

W e cannot have a vertex that does 
not belong to any object. If we want a sin- 
gle vertex in space, we must define a one- 
vertex object. For object-oriented pro- 
grammers, this structure should make 
sense, and similar structures are used in 
many three-dimensional engines. (The 
terms "three-dimensional engine" or 
"graphics engine" refer to the basic code 
that takes a three-dimensional model and 
renders it in real-time. It isseparated from 
the rest of the game code, for example 
physics simulation, scoring, and so on.) 



J osh White 

The newesf games 
increasingly rely on 
impressively ren- 
dered three-dimen- 
sional graphics. Here 
are some lips for 
creating efficient 
three-dimensional 
models in real time. 
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3D Studio objects may optionally 
contain other data, such as hierarchy rela- 
tionships between objects (parent/child) 
and animation path information, but our 
example does not. 

L ine 4 summarizes the object that 
follows, describing what kind of object it 
is (trimesh) and its basic size. 

Lines 5 through 9 show a group of 
X, Y, and Z coordinates defining the 
three-dimensional points (vertices) in 
space. T hese vertex definitions can include 
optional information such asUV coordi- 
nates, but our example does not. 

Lines 10 through 14 define a finite 
planar triangular surface known as a face. 
It is defined by referencing the vertex 
numbers (»:2 B:l C:0). Several faces can 
reference the same vertex, which is called 



So what? 

I n the .A SC file, the key is the basic 
structure of a vertex list followed by a face 
list that refers back to the vertices. U nlike 
other three-dimensional structures such as 
the crude 3DFACE entity found in .DXF 
files, a 3D Studio face cannot exist with- 
out vertices to connect to. T his is a good 
thing for real-time games because the 
simple, small data structure allows niceties 
like easy real-time manipulation of models 
(that is, three-dimensional morphing). 
You simply move the vertices, and the 
faces follow automatically. 

The downside is that 3D Studio does 
have some annoying limits in its data 
structures, mainly that it supports only tri- 
angular faces. M any game developers find 
that four-sided faces are a good solution to 



Table 1. 3D Memory Use Table 


We assume a spheric camera range with 16 points around the equator and eight levels 


from pole to pole, yielding 128 frames maximum: 






Description 


Frames 


RAM 


Original sprite (complete sphere) 


128 


524K 


Limit camera range (half sphere) 


64 


262K 


ne plane of symmetry (quarter sphere) 


32 


131K 









many problems, including convenient sur- 
faces to texture and even more efficient 
storage of models. 

Now, let's explore another kind of 
three-dimensional modeling— 3D Sprites. 

3D Sprites Tutorial 

A 3D sprite is made of a series of pictures 
of the same object from different viewing 
angles. 3D sprites are a powerful tech- 
nique for representing objects that are dif- 
ficult to build with polygons, such as 
human figures, clouds, or fire. Using 
detailed source art (even small pho- 
tographs) lets you portray convincing 
detail without slowing the game down 
with lots of polygons 

T he bad news has to do with memo- 
ry: T he many bitmaps that compose the 
3D sprite eat up RA M very quickly. T hus 
the number of bitmaps are usually under 
very strict budgets, limiting the smooth- 
ness of motion. Also, animating a 3D 
sprite takes up even more memory. M em- 
ory use is our main limitation, so this 
tutorial will concentrate on ways to reduce 
memory use in 3D sprites. W e can make a 
3D sprite by using thefollowing five steps: 

• Get a source 

• Figure the number of frames consider- 
ing range and symmetry 



"vertex sharing." This is common in 3D 
Studio files and real-time three-dimen- 
sional files alike. The faces have other 
important data such as textures or 
smoothing information, but all we care 
about for now is the vertex references and 
the material name. 

E ach face is followed by a text name 
that describes a 3D Studio "material." 
T his is a reference to a set of colors, tex- 
ture maps, and other attributes that 3D 
Studio uses to render a surface. M ost of 
the fancier settings (for example, bump 
mapping, specular highlight mapping, and 
so on) are not possible in real-time games, 
so most developers only parse the texture 
map name and settings, the basic color 
values, and perhaps the opacity mapping 
(similar to alpha channel support). 

That's it! If this information is sup- 
ported by the programmers' code, the 
simplest real-time three-dimensional 
models can be read in. 



HERE ARE THE U A D S ? 



One common question that developers ask is, "Why doesn't 3D Studio support 
four-sided faces?" There are some problems with four-sided faces (known as 
■quads") compared to three-sided faces (triangles). The most common problem, 
narping, occurs when the four corner vertices do not lie on the same plane. It is 
very hard for an artist to avoid making warped quads when creating a complex, 
organic shape. Programmers know warping results in inaccurate normals, which cause 
many problems. For example, the warped quad will disappear when viewed edge-on. 

Another problem unique to quads is an invalid shape such as a bow tie. These degenerate 
shapes often occur when a model is deformed in real time, though they can be created by 
accident (especially by ex-3D Studio modelers who are not used to quads). 

USING QUADS WITH 3D STUDIO 

If quads are supported, a simple, effective solution is to incorporate a "face combiner" 
feature in the three-dimensional file parser. This code searches for coplanar triangular 
faces that share two vertices and combines pairs of them into quads. 

If more than two faces could be combined, the parser must make a decision. Some parsers 
decide randomly; others use the "edge visibility" settings stored in 3D Studio files to 
determine which pairs of faces to combine. This allows the artist to set the divisions 
inside 3D Studio using Modify/Edge/Visible in the 3D Editor. 
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• Set the camera angles and make the 
camera position list 

• Automate the rendering and render the 
frames 

• H and off the sprite. 

Get A Source 

To make a 3D sprite, we start with a 
three-dimensional source. In theory, this 
can be a real-world object, like a sports car 
or a person. H owever, the source is usually 
a normal three-dimensional computer 
model intended for standard rendering. 
This model will never be imported into 
the game directly, so its polygon count 
and other limitations don't apply. For this 
tutorial, we'll use a three-dimensional 
model of a Porsche 911. 

Decide the Camera Range 

Next, we must decide from which possible 
positions the sprite could be seen during 
game play. To accomplish this, imagine 
that our Porsche is enclosed in a sphere, 



the surface of which is 
called the camera 
range. E ach point on 
the camera range repre- 
sents a possible posi- 
tion of the player view- 
ing the car, and each 
view is called a frame. 
F igure 1 shows the 
camera range on our 
source model, the 
Porsche. 

Can our Porsche 
be seen from any direc- 
tion (that is, any point 
on the camera range)? 
I n the worst case, such 
as an enemy plane in a 
flight simulator, it will, 
but in most cases, some 
areas can be eliminated. 
T his is good because 
the less we can see, the 
more frames we can use 



Figure 1. The Camera Rang 




Listing 2. Camera Position List: CAMPPOS.ASC 



1. 


Ambient light color: Red=0.0 Green=0.0 Blue=0.0 




2. 
3. 


Named object: 


"CamPPositon 














4. 


Tri-mesh, Vertices: 30 Faces 













5. 


Vertex 


list: 


















6. 


Vertex 


0: 


X 


0.001081 


¥ 


0.002534 


Z 


0.994797 


7. 


Vertex 


1: 


X 


-0 


155636 


V 


-0 


268908 


z 


0.944466 


8. 


Vertex 


2: 


X 


-0 


296596 


Y 


-0 


513057 


z 


0.798534 


9. 


Vertex 


3: 


X 


-0 


407624 


¥ 


-0 


705364 


z 


0.571674 


10. 


Vertex 


4: 


X 


-0 


477557 


¥ 


-0 


826492 


z 


0.286697 


11. 


Vertex 


5: 


X 


-0 


499364 


¥ 


-0 


864262 


z 


-0 


007422 


12. 


Vertex 


6: 


X 





0013 


¥ 





002534 


z 





944466 


13. 


Vertex 


7: 


X 


-0 


155636 


¥ 





273977 


z 





944466 


14. 


Vertex 


8: 


X 


-0 


296596 


¥ 





518126 


z 





798533 


15. 


Vertex 


9: 


X 


-0 


407624 


¥ 





710432 


z 





571674 


16. 


Vertex 


10 


: X 


-0 


477557 


¥ 





83156 


z 





286696 


17. 


Vertex 


11 


: X 


-0 


499364 


¥ 





86933 


z 


-0 


007422 


18. 


Vertex 


12 


: X 





001286 


¥ 


-0 


298214 


z 





932635 


19. 


Vertex 


13 


: X 





001274 


¥ 


-0 


610524 


z 





783235 


20. 


Vertex 


14 


: X 





001266 


¥ 


-0 


885267 


z 





455405 


21. 


Vertex 


15 


: X 





001258 


¥ 


-0 


992485 


z 


-0 


007423 


22. 


Vertex 


16 


: X 





001286 


¥ 





303283 


z 





932634 


23. 


Vertex 


17 


: X 





001274 


¥ 





615592 


z 





783235 


24. 


Vertex 


18 


: X 





001266 


¥ 





890335 


z 





455405 


25. 


Vertex 


19 


: X 





001258 


¥ 





997552 


z 


-0 


007424 


26. 


Vertex 


20 


: X 


-0 


346193 


¥ 





002534 


z 





932634 


27. 


Vertex 


21 


: X 


-0 


557221 


¥ 





261643 


z 





783235 


28. 


Vertex 


22 


: X 


-0 


557221 


¥ 


-0 


256575 


z 





783235 


29. 


Vertex 


23 


: X 


-0 


753137 


¥ 





47179 


z 





455405 


30. 


Vertex 


24 


: X 


-0 


852744 


¥ 





002534 


z 





516384 


31. 


Vertex 


25 


: X 


-0 


753137 


¥ 


-0 


466722 


z 





455405 


32. 


Vertex 


26 


: X 


-0 


80824 


¥ 





590785 


z 


-0 


007424 


33. 


Vertex 


27 


: X 


-0 


977282 


¥ 





210601 


z 


-0 


007424 


34. 


Vertex 


28 


: X 


-0 


977282 


¥ 


-0 


205533 


z 


-0 


007424 


35. 


Vertex 


29 


: X 


-0 


80824 


¥ 


-0 


585717 


z 


-0 


007423 



























to show the rest of the model. 

For example, if the car is placed in a 
open (but inaccessible) garage, the garage 
blocks the viewer from ever seeing the 
back of the car. W e don't have to store 
any frames that show the back, because it 
can't be seen during the game. T his leaves 
us with just half (or less) of the camera 
range we had. 

Use Planes of Symmetry 

O ur car has a plane of symmetry, that is, 
one half is a mirror image of the other 
half. By writing game code that mirrors 
the frames at run time, the game can sim- 
ulate both sides of a symmetrical object. 

If our object is radially symmetrical, 
like a glass bottle, we can reduce our frame 
count even further. We only need one 
viewing angle in the horizontal direction, 
decreasing our camera range drastically. 
Of course, this won't work for our car. 
W ith its plane of symmetry, our camera 
range is now a quarter-sphere. 

Figure the Number of Frames 

N ext, we must decide how many frames of 
our sprite will be available within the 
game. T his depends on the available 
RAM , the size of the bitmap, the color 
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depth, and the compression (if any) of the 
bitmap in memory. 

For our example, let's say we will 
have 128K of memory available for this 
sprite, bitmaps will not be compressed, 
and our game will use 8-bit color. Table 1 
shows a 3D sprite memory use table. This 
gives us 30 bitmaps of 64-by-64 pixels. If 
the programmers don't know how much 
memory will be available for this object, 
don't render the sprites until the coding is 



farther along and the mem- 
ory resources are more 
defined. 

Set the 

Camera Angles 

Once we know how many 
frames we can use, we must 
decide which angle they 
will show; that is, which 30 
viewing directions in the 
camera range are most 
important? Figures 2a and 
2b show the camera posi- 
tions on a sphere (top and 
side views). T he obvious 
starting point is a simple 
latitude and longitude grid 
over the quarter sphere, but 
there are other factors to 
consider: 

The latitude and lon- 
gitude distribution is not 
ideal because the points are 
closer to the poles. A better 
starting point would be a 
geodesic sphere. This soc- 
cer-ball-type arrangement 
distributes the points evenly 
over the surface of the 
sphere. 

The most likely view- 
ing angles should have 
more frames because we 
prefer the model to move 
smoothly when it is seen 
most often. 

A complete coverage 
is also important. I f we 
completely leave out large 
areas of the camera's range, 
the model will appear to 
jump when viewed from 
those areas. 
T he shape and appearance of the 
model must be considered. If our object 
was a lollipop, we would use fewer frames 
in which the stick wasn't visible because 
jerky motion would be less noticeable with 
the stick absent. 

H ere's how to create the camera 
locations using 3D Studio. (Before 
actually doing this, set the coordinate 
labels correctly). When 3D Studio cre- 
ates .DXF files— and .ASC files, too— 



theY and Z coordinates are swapped by 
default. You can fix this by setting the 
coordinate labels in the 3D S. SET file 
as follows. (Remember to save the old 
settings!): 

H-LABEL = Z 
W-LABEL = X 
D-LABEL = Y 

After you've reset the settings, follow 
these steps: 

1. Use Create/G Sphere/ Faceted to create 
a geodesic sphere around your object. 
The "Values" setting should be set to 
196 faces, yielding 30 points on a quar- 
ter-sphere. The exact number of faces 
you want will vary (when in doubt, 
choose more). The sphere should have 
a radius of 1 and be centered at 0,0,0. 
Choose an appropriate name like cam- 
position. 

2. E rase the faces of the sphere that are 
totally outside your camera range; that 
is, three-quarters of the sphere. Erase 
the isolated vertices. 

3. Choose M odify/O bject/A ttributes to 
check how many vertices remain. If the 
number of vertices is less than your tar- 
get amount, you must use a GSphere 
with more vertices in Step 1. Other- 
wise, use M odify/Vertex/D elete to 
erase the extras that are farthest from 
your camera range. 

4. M ove the vertices into the camera 
locations you've chosen. Use M odi- 
fy/Axis/Place to set the axis in the 
center of the sphere and use M odi- 
fy/Vertex/ Rotate to move the ver- 
tices. Using a rotation around the 
center of the sphere will keep the 
vertices on the sphere's surface. If 
you use other editing commands and 
accidentally move the vertices off the 
surface, create a second sphere 
(repeat Step 1), freeze it, and com- 
pare your distorted vertices to its cor- 
rect surface. 

5. Select the object and save it to a .3D S 
file (in the File menu, choose Save 
Selected). Load that 3D S file. 

6. D elete all the faces in the object, keep- 
ing the isolated vertices. 

T his is your model of the camera 
positions. 
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Make the 

Camera Position List 

Depending on what we plan to do with 
the camera position list, we will save it as a 
.3DS , .ASC, or .DXF file. We'll have to 
know more about how the rendering 
engine incorporates sprites before we 
decide, but somehow we have to provide 
this list. The rendering engine will use the 
list to determine which frame to show 
when the player is able to see the sprite. 

For the simplest format, save your 
information as an .ASC file, then open 
the file in a normal text editor. T he list of 
vertices that follow the object name is your 
camera position list. They should look 
something like the CAM POS.ASC file 
listing, shown in L isting 2. 

Automate the Rendering 

T he next step is to render each frame from 
each camera position. We could simply 
create a camera at each location and ren- 
der it, but there's a tricky, handy way to 
automate this. T he idea is to create a sin- 
gle camera that jumps from point to point 
in the Keyframer. Follow these steps: 

1. Save your original file as a .DXF file 
with one layer. 

2. F ix the .DXF file. L isting 3 shows the 
CAM POSE .DXF file. 

W hen you save a .DXF file from the 
3D Editor, 3D Studio cannot import it 
as a path because it assumes you're sav- 
ing a surface, not a line. H ere's how to 
get around this problem: 

1. Open the .DXF file in a text 
editor. Search for ENTITIES. Look 
on the screen for polyline, a few 
lines down. 

2. M ove down to the line that has 
70 all by itself (about five lines 
down from POLYLINE). 

3. The number on the next line 
after 70 should be 8, not 64. 
C hange this number, save, and exit. 

3. Create a camera, go to the Keyframer, 
and set the number of animation 
frames (animation length) to one more 
than the number of camera positions 
you have. 

4. C hoose Paths/G et/D isk. I n the file 
dialog box, choose the .DXF file you 
just saved. I n the next dialog box, make 
the camera move to the path start, and 



Listing 3. CAMPOS.DXF 



[ Lines omitted: The first 147 lines are 
the "header" section and are not used by 
30S; in fact, they can be deleted. 



SECTION 
2 

ENTITIES 


POLVLINE 
8 

CANPOSITON 
66 

1 

70 
8 
71 
30 
72 



VERTEX 

8 

CABPOSITON 
10 

0.001081 
20 

0.002534 
30 

0.994763 
70 
192 


VERTEX 

8 

CANPOSITON 

10 

-0.155636 
20 

-0.268908 
30 

0.944432 
70 
192 

[ Lines omitted: The "0 I VERTEX .. 
block repeats for each of the 30 »ertices. 





VERTEX 
8 

CAHPOSnON 
10 

-0.296596 
20 

-0.513057 
30 

0.798500 
70 
192 


VERTEX 
8 

CABPOSnON 
10 

-0.808240 
20 

-0.585717 



30 

-0.007457 
70 
192 


SEQEND 
8 

CAMP0SIT0N 


EN0SEC 


EOF 



do not allow the keys to be adjusted for 
constant speed. 

5. C hoose Paths/Show-H ide and click on 
the camera to see the path. T he camera 
will now have a path with a keyframe 
for each position in the list. 

6. C heck to see that the last two anima- 
tion frames are the same camera posi- 
tion; if so, reduce the animation length 
by one. If they are not, there may be 
more camera positions that are not 
shown. Increase the animation length 
and reload the path. 

Render the Frames 

O nee the camera is set up, we render the 
images, saving each one to a separate file. 
W hen rendering, we will have to deal with 
thefollowing problems: 

• Backgrounds The object must be isolat- 
ed from its background during render- 
ing. Using alpha channel is ideal but is 
not often supported in real-time games. 
If alpha channel is unavailable, set the 
background color to an RGB value that 
will not appear in the rendered object. 
T his is the easiest way for graphics 
engines to separate the sprite from its 
background. 

• Perspective. W e have to choose a com- 
promised perspective angle ("fish-eye 
vs. zoom" camera setting) when we 
render because the perspective doesn't 
change during gameplay. Base the 
amount of perspective on how the 
object will be most commonly viewed. 
Generally, err on the side of less per- 
spective. 

• Rendering Size The goal is to make full 
use of the final 64- by- 64- pixel frame. 
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Figure 3. A Fully Rendered Frame 




M inimize empty space by spending 
time with the field- of-view camera set- 
ting, carefully getting as many frames as 
possible to completely fill the rendered 
bitmap. Usually, it is necessary to use 
the same camera settings for all frames; 
otherwise, the sprite will appear to grow 
or shrink during gameplay. Because 
many frames will inevitably have large 
areas of background, it will pay to store 
the frames using some simple compres- 
sion algorithm like RLE memory. 

• Lighting and Effects. There aren't any 
real limits here, but lighting will 
appear to be symmetrical if we are tak- 
ing advantage of planes of symmetry. 
For example, if we put a blue spotlight 
on the left side of the model and we 
use a plane of symmetry, blue lights 
will appear on both sides of the model 
when it's in the game. This also 
applies to shadows and other effects. 

• Redundant F rames. If we can't see a dif- 
ference between any two frames, one of 
the frames is redundant and unneces- 



W H V 3D STUDIO? 



sary, even if the frames were rendered 
from very different angles. W e can have 
the two different viewing angles refer- 
ence the same bitmap, which saves 
memory. 



Hand Off the 3D Sprite 

Once we've rendered, all that remains is 
for us to check all the files for errors and 
give them, with the camera position list 
file, to the programmers. This is all the 
material they need to integrate the 3D 
sprite into the game. Figure 3 shows our 
first rendered frame. 

Real-Time Art— If s Great! 

Let's end with something for the artiste in 
all of us. A s creative developers, especially 
artists, the limits of real-time three- 
dimensional modeling are a stiff price to 
pay, but what we get is the freedom of a 
whole new medium. ur art is not locked 
onto a camera path or frozen into a single 
frame. 

T he players are free to explore our art 
like kids on a playground— crawl around 
under it, fly over it, or bump along with 
their virtual noses pressed against it. It's 
truly the next step in computer art, and 
well worth learning. ■ 



Josh White is a partner in Vector 
Graphics, building real-time three-dimen- 
sional models for game and virtual reality 
developers. H e can be reached via e-mail 
at vectorg@crl.com or through Game 
Developer magazine. Josh is a frequent 
poster on rec.games.programmers and 
comp.graphi cs. packages.3dstudi o, so look 
out for him there. 



■ n this article, I refer specifically to AutoDesk's modeling software 3D Studio 

I because it is commonly used to build real-time models. Many other significant 

I modelers- for example, Caligari TrueSpace- also support 3D Studio's file for- 

I mats. I mention this because it is only fair to point out that there are other model- 

I ers you can use. 

WHY .ASC? 

3D Studio allows many types of three-dimensional file formats to be saved, such as .PPRJ , 
.DXF, .ASC, and .3DS. This article explores the .ASC format, simply because it is stored as a 
text file and is the most self-explanatory. Many programmers support the binary ,3DS for- 
mat instead, but it's beyond the scope of this article. 

WRITING 3D STUDIO FILE PARSERS 

If you want to write code that reads or writes the .3DS files that 3D Studio generates, the 
,3DS file format is documented in AutoDesk's 3D Studio R3 File Toolkit, and the author, 
Grant Blaha, usually answers questions on the free 3D Studio e-mail list at 
majordomo@ autodesk.com. 

FREE INFORMATION 

Documentation on file formats, including 3D Studio, is also available via ftp on avalon.chi- 
nalake.navy.mil and on the ftp site for game programmers, x2ftp.oulu.fi. 
To learn more about 3D Studio from other users: 

• Send e-mail to majordomo@autodesk.com with the subject "subscribe 3dstudio." To 
unsubscribe, e-mail majordomo@autodesk.com with the subject line "unsubscribe 
3dstudio." Don't write the list alias itself; this will annoy the natives. 

• Check out the USENET newsgroup alt.3d.studio if you can. This is better than subscrib- 
ing via majordomo@autodesk.com because you don't get bombarded by e-mails 
whether you want them or not. 
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Rise 
-the Triad 



Wayne Sikes 

The world within Rise 
of the Triad is largely 
possible thanks to 
innovative ray-casting 
techniques. Wayne 
Sides looks at Apogee's 
use of mashed walls, 
floor sound tiles, and 
columnar storage of 
image data. 



On the C hopping B lock this 
month is R ise of the T riad by 
A pogee Software. R ise of the 
Triad is a scrolling, first-per- 
son perspective three-dimen- 
sional action game. The fast 
action constantly challenges 
your reflexes. T riad has a high 
entertainment factor as well. You'll 
come up against clever devices and haz- 
ards such as fire chutes and jets that can 
burn you to a crisp, poison gas jets that 
can be triggered by opening doors or 
throwing a wall switch, rotating blades 
that appear out of the floor or ceiling, 
and movable walls that can crush you 
against another wall. 

T he use of features such as jump 
pads that propel your character into the 
air to grab suspended objects and G ravi- 
tational Anomaly D isks that move up 
and down or travel over the ground in 



predefined pathways adds an extra level 
of creativity and originality. I found some 
elements of the game such as the "D og 
M ode" power- up (as opposed to "God 
M ode") very amusing. And we mustn't 
overlook the Violence Level adjustment 
for tailoring the blood- and-guts graphics. 

T he primary T riad executable, 
ROTT.EXE.isa little over 1M B. Triad 
was written with the W atcom C/C ++ 
Run-T ime system. T he game runs in 
protected mode using the DOS4GW 
DPM I system by Rational Systems. The 
engine contains a large number of sys- 
tem diagnostics and error detection rou- 
tines, which are especially useful when 
you're designing new game levels. 

How Does it 
Look and Sound? 

The graphics techniques used in creat- 
ing the T riad environment are very 




Apogee has upped the ante on Rise o 
intended for Wolfenstein 2. 



ray-casting engine, which was originally 
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Listing 1. WAD File Structures 



// Header structure, 
typedef struct 
{ 

char identification [4] ; 
long numlumps; 
long infotableofs; 
} WADHEADER, *PWADHEADER; 

// Directory structure. 

typedef struct 

{ 

long filepos; 
long size; 
char name [8]; 
} LUMPS, *PLUMPS; 

// Basked object (actors and sprites) structure. 

typedef struct 

{ 



short origsize; 
short width; 
short height; 
short leftoffset; 
short topoffset; 
short collumnofs[320] ; 



// the orig size of "grabbed" gfx 
// bounding box size 

// pixels to the left of origin 
// pixels above the origin 
// only [width] used, the [0] is 
// Sicollumnofs [width] 



} PATCH, *PPATCH; 



// Transparent object structure. 

typedef struct 

{ 

short origsize; 
short width; 
short height; 
short leftoffset; 
short topoffset; 
short translevel; 
short collumnofs[320]; 



// the orig size of "grabbed" gfx 
// bounding box size 

// pixels to the left of origin 
// pixels above the origin 

// only [width] used, the [0] is 
// Sicollumnofs [width] 



} TRANSPATCH, *PTRANSPATCH; 



Note: These structure examples are given in the Official ROTT Specifications file, R0TSP1, by 
Apogee Software. 



interesting. The Triad world is rendered 
with a ray-casting algorithm that uses a 
90° field of view. Do not assume that 
this is just another run-of-the-mill ray- 
casting engine. Apogee has upped the 
ante on ray casters with its Triad engine. 
riginally, A pogee projected this engine 
for use in Wolfenstein 2. Later, the 
company refined it into the Triad game 
engine. In fact, many of the graphic 
images in Rise of the Triad were origi- 
nally intended for W olfenstein 2. 

Further rendering on Triad is 
achieved using 320- by- 200- pixel graph- 
ics in M odeX. (M any game engines that 
originally rendered their graphics using 
320- by-200-pixel M ode 13h are now 
switching to M ode X.) Triad's develop- 
ers optimized the ray caster for speed 
and used well- developed methods for 
achieving high frame rates while keeping 
the graphics clean. 

For example, consider the case of 
masked walls— walls you can see 
through. T hese walls may be actual walls 
containing glass windows or gratings you 
can look through or they may take the 
form of physical barriers such as picket 
fences. Older ray casters rendered these 
walls using two separate castings. The 
first casting would locate and render the 
wall farthest away from the viewpoint, 
and the next casting would locate and 
render the masked wall on top of the 
wall rendered with the first cast. You 
could then look through a transparent 
area in the closest wall and see the back- 
ground wall. 

This method demands a large 
chunk of system time and achieves mar- 
ginal frame rates. The Triad ray caster 
renders masked walls as "patches" placed 
on top of background walls or other 
objects. Essentially, only one ray cast is 
done, the background is rendered, and 
finally the masked wall is scaled, rotated, 
and drawn to fit on top of everything 
else. The patch looks great and can be 
done quickly. 

Another feature of the ray caster 
Triad uses is its ability to draw walls of 
varying heights. Ider ray casters gener- 
ated environments that had a very blocky 
appearance. The variable- height envi- 
ronment of the Triad world makes it 



// Structure used for floor and ceiling data. 

typedef struct 

{ 

short Uidth, Height; 
short Qrgx.Orgy; 
} FLOQRCEILING, *PFLOQRCEILING; 



appear much more realistic. Each Triad 
game map contains height information 
that instructs the engine to render the 
world using one of 16 possible heights. 

T he sky background is another area 
where the engine really shines. Rather 
than simply drawing background sky and 
ground or floor textures followed by the 
ray caster overlaying its data on top, the 
T riad engine draws the sky as a series of 
image tiles. Areas of visible sky are tiled 
into the Triad world. Using the player's 
current viewing angle and altitude, the 



engine renders the appropriate piece of 
the sky area. T he end result is a realistic 
sky background that required only a 
small amount of system time to generate. 

Because the sky background repre- 
sents the boundary of the Triad world, 
some interesting effects can be designed 
into the game's maps. For example, 
because the T riad world ends at the edge 
of the floor or ground map tiles, you can 
fall off the edge of the world when you 
intentionally (or accidentally) step off a 
floor tile. 
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The tiles used for mapping player 
floor area are one of the more interesting 
aspects of Triad levels. H ow can floors 
be interesting you ask? Some grid- based 
games delegate floor space by assuming 
that all area enclosed by walls is floor 
space. I n T riad, the floor space is specifi- 
cally marked with floor tiles. These tiles 
are not images or floor textures; instead, 
they are referred to as "floor sound tiles." 
The engine uses the values of the floor 
tiles to determine how to distribute the 
various game sounds. For example, if 
you're standing on a floor tile that has 
the same value as the tile under a hazard 
such as a fire chute, you will hear the 
sound made by the fire chute. Alterna- 
tively, if you're on a floor tile that is dif- 
ferent from that under the hazard, you 
will not hear the hazard. You can cre- 
atively exploit this feature when design- 
ing maps. 

Primary Data Storage 

M ost of the graphic and sound data is 
stored in DARKWAR.WAD. This file 
is about 14.6M B and has the same for- 
mat as the Id Software WAD file used 
in D oom. L isting 1 shows example code 
for several WAD file structures. (The 
structures in Listing 1 are contained in 
Apogee's Official ROTT Specs file, 
ROTSP1. You can find this file on 
CompuServe in the 3-D Action Games 
library of the Action Games forum (GO 
ACTION). I included the patch, trans- 
parent patch, and floor and ceiling struc- 
tures just in case you want to look at 
these objects while examining the WAD 
file. The data in DARKWAR.WAD is 
grouped according to type. For example, 
most of the wall data is stored between 
the W A L L ST RT andWALLSTOP 
directory entries. 

M ost of the graphic data in T riad is 
stored using a particularly interesting 
method. The Triad bitmap data is stored 
in columnar format. M ost drawing pro- 
grams usually store their image files 
using formats such as PCX. The bitmap 
data is stored in row x column format. 
This is not the best storage format for 
rendering images in ray- cast environ- 
ments, because ray-cast data is rendered 
as a sequence of vertical lines. W hen 



storing data in its final WAD format, 
A pogee converts the row x column 
bitmap data into column x row format, 
which speedsthe rendering process. 

Map Fundamentals 

Triad map files have either an RTL or 
RTC suffix. RTL files are used mainly 
for single- player games, and RTC files 
are designed for ROTT Comm-bat 
(multiplayer) games. T he primary differ- 
ence between these two files is that the 
RTC files contain no computer- generat- 
ed enemies or exits. 

Both map file types have the same 
internal format: an 8-byte version struc- 
ture, a block of 100 map header struc- 
tures that contain (among other things) 
the size and location of the map data, 
and the map data stored in compressed 
Run Length Encoded (RLE) format. 
L isting 2 gives version and header struc- 
tures for T riad map files. (T he structures 
given in L isting 2 are contained in 
A pogee's Official ROTT Specs file, 
ROTSP1.) 

The VERSION structure contains the 
file's RTL or RTC signature plus the file 
format version specification. Each map 



Listing 1. Map File Structures 



#define NUHPLANES 3 

#define ALLQCATEDLEVELNABELENGTH 24 

#define KALL.PLANE 

#define SPRITE.PLANE 1 

#define INFO.PLANE 2 

// Version structure, 
typedef struct 
{ 

char Signature[4] ; 

unsigned long Version; 
} VERSION, *PVERSI0N; 



file contains 100 RTLMAP structures with 
each structure corresponding to a stored 
map. T he Used variable indicates whether 
or not a map is stored in this map slot. 
RLEWtag is the encoding tag used for 
compressing and decompressing the map 
data. The Planestart and Planelength 
arrays contain the offset positions and 
lengths of the map data. 

When uncompressed, each Triad 
map consists of three planes of data. 
Each plane is an array of 128- by- 128, 
16-bit words. At first glance, the map 
data format is somewhat confusing. It's 
easiest to view the map as a grid of 128- 
by-128 map cells. (I use the reference to 
Triad map "cells" because most of us are 
familiar with spreadsheet programs that 
have their data in cells.) A map cell is 
composed of three values— one value 
from each of the three map planes. E ach 
plane contains unique data, and we can 
label the planes as the W all Plane, the 
Sprite Plane, and the I nfo Plane to help 
simplify this concept even more. 

T he W all Plane contains (as you 
probably already deduced) the data for 
the vertical walls. T riad walls also consist 
of objects such as wall switches, doors, 



// Header structure. There are 100 of these in each file, 
typedef struct 
{ 

unsigned long Used; 

unsigned long CRC; 

unsigned long RLEWtag; 

unsigned long HapSpecials; 

unsigned long Planestart[ NUHPLANES ]; 

unsigned long Planelengthf NUHPLANES ]; 

char Name[ ALLOCATEDLEVELNAHELENGTH ]; 

} RTLHAP, *PRTLHAP; 



Note: These structure examples are given in the Official ROTT Specifications file, R0TSP1, by 
Apogee Software. 



56 GAME DEVELOPER - AUGUST/SEPTEMBER 1995 



CHOPPING BLOCK 



transparent windows (you can shoot the 
glass out), gratings, fences, and arch- 
ways. For mapping purposes, the W all 
Plane also contains the floor sound tiles. 

The Sprite Plane holds most of the 
visible objects in the game such as enemy 
players, light fixtures, power- up objects 
that give you health, hazards such as 
rotating blades and knives that periodi- 
cally cycle in and out of the floor or ceil- 
ing, jump pads, boxes, and trees. Path 
information is also stored in this plane 
and is used for controlling the movement 
of game- generated enemies and walls 
that can be moved or pushed. 

The Info Plane provides a very ver- 
satile method for storing height, song, 
X and Y coordinates, exit, and minute 
and second time data. For example, 
some game objects can have height 
above the player floor level. To specify 
an object's height, the object is loaded 
into the Sprite Plane, and its height is 
stored in the Info Plane. In another 
example, you can control many game 
objects using wall switches. To program 



a door that is controlled by a switch, the 
door object is placed in the W all Plane, 
and the X and Y coordinates of the 
controlling wall switch are placed in the 
door's Info Plane. Special data such as 
sky tiling are also stored in the Info 
Plane. 

Want To Design 
Your Own Maps? 

Triad map data can be very tedious to 
edit by hand, plus you can easily make 
many mistakes (as I found out). I found 
the Triad maps interesting enough 
(and fun enough) to warrant writing a 
map utility that edits existing maps and 
also lets you create new ones. The edi- 
tor, ROTTED, is a full-featured, easy- 
to-use W indows system that edits 
T riad maps using a simple image tiling 
system. (The attractive image tiles were 
provided by Apogee Software.) You 
can find ROTTED.ZIP on Com- 
puServe in the 3-D Action Games 
library of the A ction G ames forum 
(GO ACTION). 



Not Another 
Doom Wannabe 

M any Doom clones have appeared in 
recent months, but Triad isn't one of 
them. It has enough outstanding features 
to be in a category by itself. T he ray- cast- 
ing engine is unique, the game world con- 
tains several hundred creative objects and 
actors, and the mapping system is one of 
the most flexible that I have seen. The 
A pogee "D evelopers f I ncredible Power" 
are definitely living up to their name! ■ 

Wayne Sikes has been a computer 
hardwareand software engineer for the last 
12 years. He has an extensive background 
in C, C++, and assembly language pro- 
gramming. H e also has several years experi- 
ence asa computer systans intelligence ana- 
lyst, a field in which he specialized in ded- 
phering and disassembling computer code 
while working on dassified government 
projects. H ehas written numerous computer 
gaming help utilities. You can reach him via 
email at 70733.1562@compuserve.com or 
through Game Developer magazine. 
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David Sieks 

When you first studied 

art. mere you using o 
computer? Probably 
not. Here ore some 
tools that let three- 
dimensional artists 

get bach to their roots 
and apply many 

traditional techniques 
electronically. 



There is something intrinsically 
convincing about a three- 
dimensional rendering. Even 
when an extremely photoreal- 
istic effect has not been 
attempted, the visual cues 
inherent to three-dimensional 
art still manage to satisfy the 
subconscious in some basic way. For 
the artist, a good three-dimensional 
design package can facilitate the real- 
ization of creative vision and remove 
barriers to expression, imbuing even 
fantastic images or effects with uncan- 
ny authenticity. 

I enjoy working in three dimen- 
sions because it allows me to flex differ- 
ent creative muscles than "working flat." 
W hen I 'm working in the three-dimen- 
sional environment, my role is more 
akin to that of sculptor, lighting and set 
designer, costumer, makeup effects 
artist, and puppeteer all rolled into one. 
H owever, beyond the challenges of 



these various roles and the challenge of 
mastering the modeling and rendering 
software itself, three-dimensional 
design presents the artist with another 
more insidious challenge: maintaining 
an identity. 

Convincingly solid though the 
images may be, and despite the possi- 
bilities of numerous special effects, 
many three-dimensional images can 
tend to display a certain homogeneity. I 
do not imply that creativity and talent 
are in less demand when you use this 
medium, nor do I suggest that these 
qualities are less evident in a three- 
dimensional rendering. 

Too often what is lacking, howev- 
er, is what we might call evidence of the 
artist's hand. In a two-dimensional 
work, the personality of the artist 
resides closer to the surface; even when 
the computer is used to create the 
image, a less digital gimmickry exists 
between concept and product. W hen 




Handcrafted character is a mouse click away. It took less than a minute to transform a ray- 
traced truSpace image into an impressionistic painting using the Auto Van Gogh feature in 
Fractal Design's Painter 3. An essentially infinite array of tools and user-defined settings let 
you make subtle or sweeping changes automatically or one brush stroke at a time, to imitate 
all sorts of natural media materials and surfaces. 
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depth is created not by a sophisticated 
algorithm but by the mind, eye, and 
hand of the artist, that is a small sort of 
magic. I n many cases, an artist's sketch- 
book will contain more of the unique 
flair and flavor of that artist than the 
final texture- mapped, light-sourced, 
fully rendered image or animation. 

T he blurring of individual style that 
is, not infrequently, a by-product of 
three-dimensional art can even be 
viewed as advantageous. W hen several 
artists contribute to a game's graphics, 
the unintentional homogenizing effect of 
three-dimensional rendering can work to 
lend a uniformity of appearance to the 
final whole. Yet while it may be desirable 
for the different graphic elements of 
your game to have constancy, it is less 
than desirable for that game to look like 
everyone else's game. D istinctive graph- 
ics can be one of the first hooks to 
attract a game buyer to your title. 

Three-dimensional modeling and 
rendering tools should not be viewed as 
a shortcut or a high-tech trick, but as 
one more medium that we as artists 
must work to make the most of. The 
novelty has been worn thin enough that 
we— and the game- buying public— can 
begin to see beyond the superficial grati- 
fication provided by shadowmaps and 
perfect specular highlights and now 
want more. M erely using three-dimen- 
sional tools to render title screens, cut 
scenes, backgrounds, sprites, or any 
other game element is not in itself going 
to score anyone a lot of points. 

The coming generation of fast- 
twitch, real- time- rendered- on- the- fly, 
three-dimensional games will still be 
buoyed by the "Gee whiz" factor. But 
prerendered three-dimensional material 
is no longer news and viewers will look 
at it with an increasingly jaded eye as 
the inevitable "H o-hum" factor sets in. 
As artists, we must continually strive to 
keep the visual elements of our games— 
from title sequence to gameplay and 
everything in between— as distinctive 
and compelling as we know how. 

Using What We Know 

Before coming to the computer, most of 
us had our artistic roots in drawing and 



painting on paper or canvas. For me, 
those experiences— and the years spent 
developing my own approach to that 
work— remain one of the cornerstones 
of my artistic sensibility and continue to 
influence my work in digital media 
today. If you're interested in translating 
the hands-on quality and distinctive 
personal style of natural media to the 
digital medium, then you'll want to take 
a look at Painter. In its third release, 
Painter, from Fractal Design, brings to 
the computer screen a staggering array 
of effects amazingly similar to those cre- 
ated with traditional art materials like 
pen and ink, airbrush, watercolor, or 
even glossy, gloppy impasto oils. 

Primarily an illustration package, 
Painter— with your help— can create 
stunning images that are all the more 
amazing because they look for all the 
world like they were created not on the 
computer but at an easel. The range of 
possibilities is essentially limitless, with 
so many variables provided to affect the 
look of an image that you will while 
away countless happy hours experiment- 
ing with different techniques and still 
discover new surprises— surprises you 
can then pass on to the players of your 
game. 

In Painter, you work with "brush- 
es" of user- defined shape and size, even 
allowing control over the action of the 
virtual bristles— with settings for thick- 
ness, dumpiness, and hair scale. You are 
also able to control the action of the 
brush stroke, which can be predefined to 
be made up of smaller multiple strokes 
of different colors for a soft, impression- 
istic effect. The marks you make mimic 
the appearance of pencil, crayon, mark- 
er, chalk, charcoal, oil pastel, pen and 
ink, scratchboard, watercolors, oils, and 
airbrush— each with its own menu of 
variations. 

You can further manipulate the 
image with the simulated effect of an 
eraser, droplets of water, bleach, the 
darkroom techniques of dodging and 
burning, and masking that allows hard 
or feathered edges or even conforms to 
the texture of the surface you work on. 
Yes, I know you're working on paper or 
canvas, but your audience won't: Painter 



lets you select a virtual surface on which 
to work. T his can be as smooth and fea- 
tureless as the screen of your typical 
painting program, or can look like a 
wide variety of interesting textures that 
can be customized to suit your needs. 
The art materials you use interact with 
the selected surface much like their nat- 
ural media counterparts. 

T here's almost too much in Painter 
3, and the system of "drawers" and 
dropdown menus and pop-up dialogs 
with multiple slider controls can be a bit 
bewildering to navigate at times. Docu- 
mentation is a bit thin but is generally 
sufficient to point you in the right direc- 
tion. M ore help can be found in Inside 
F ractal D esign Painter 3.0 (M acmillan) 
and Artistry, a Painter newsletter pub- 
lished 10 times a year, both by Karen 
Sperling. H appily, your customized 
brushes, textures, color sets, and "ses- 
sions" of applied effects can be named 
and saved, so once you figure something 
out you can keep it for later use. 

The sheer range of visual styles 
possible with Painter and the unexpect- 
edness of such natural media techniques 
on the computer screen should start 
some ideas percolating in your head 
already. But more than just a way to 
paint without making a mess, this pro- 
gram throws in the abilities of a power- 
ful image editor and a capable animation 
tool. 

Existing images or animations can 
be opened in Painter and treated to sub- 
tle retouching using any of the painting 
tools or plug-ins including most Photo- 
shop filters. Or they can be cloned and 
completely reworked. By recording a 
session, it's possible to apply an effect or 
multiple effects to an entire animation, 
introducing a surface texture or causing 
the whole to appear rendered by the 
staccato dabblings of impressionist mas- 
ter George Seurat, for example. I've 
been experimenting with various 
painterly effects to rework three-dimen- 
sional stills and even whole animations. 
The results nicely combine the authen- 
ticity of the three-dimensional render- 
ing with the freshness and vitality of an 
actual painting. You wouldn't use this 
sort of effect for everything, but it can 
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be a great way to tone down the slick- 
ness of a three-dimensional image for a 
historical period setting or whenever you 
might want a more painterly, personal 
look. 

Another neat crossover between 
Painter and your work in three-dimen- 
sional graphics is the ability to create 
your own seamless tiles with Painter's 
Capture Pattern utility. A wraparound 
color technique causes marks that stray 
off the edge of your pattern to continue 
on the opposite side. So you can easily 



three-dimensional animation or more 
sophisticated animation effects software, 
however, Painter may seem a bit under- 
featured in this department. Except 
when applying a prerecorded session to 
an entire animation (called a Frame 
Stack in Painter), you're pretty much 
drawing frame by frame. nionskinning 
lets a series of subsequent frames show 
through, one on top of the other (as 
many as five at a time), which aids in 
progressing a movement through its var- 
ious stages. A tracing paper function 



mations. Users of that earlier title will 
be comfortable with most of the meth- 
ods and conventions utilized here, 
though the switch from DOS to Win- 
dows has simplified and improved some 
processes. To get Animator Pro users 
quickly up to speed, the changes have 
been well documented and the tutorials 
take nothing for granted. 

M oving beyond the capabilities of 
Animator Pro, the animation functions 
now exist as the main of four supporting 
modules: Animator, Soundlab, Scriptor, 




use Painter's various media looks and 
surface textures to create your own 
materials to map to three-dimensional 
objects. 

Creating an animation in Painter is 
very much akin to the traditional eel 
techniques of film animation. T hat is, it 
lacks a lot of the improvements that 
more dedicated animation software can 
provide, like tweening between 
keyframes and morphing one shape into 
another. 

If you're experienced in eel anima- 
tion, moving the sketching, inking, and 
painting of frames off the peg bar and 
onto the computer will seem a real 
boon. (M ost animation houses have 
abandoned eels and computerized these 
processes as well.) If you're used to 



also allows rotoscoping, so that digitized 
video can be reinterpreted by hand, 
which can be a lifesaver when it comes 
to capturing the timing and nuances of 
human or animal movement in a hand- 
drawn scene. 

Editing from Autodesk 

A nother way to get the most out of your 
digital animations is to polish them in 
post with a suite of sophisticated editing 
tools, and your old friends at Autodesk 
want to help. "Sound, paint, and 
motion. . .C omplete 2D animation for 
W indows" is how the company bills its 
brand new Animator Studio. This is 
more than just an update of Autodesk's 
popular Animator Pro— indeed, it is all 
you need to make walking, talking ani- 



and Player. Soundlab is a very usable 
editor that lets you create and filter 
audio files and synch them with your 
animations. P layer runs A V I , F L I , 
FLC, and Quicktime files and can be 
freely distributed. Scriptor is intended to 
string together animation and audio files 
for presentations or self- playing shows, 
but in its first release I found it still 
quite buggy. H opefully, Autodesk will 
have released patches to remedy these 
problems before you even have a chance 
to read about them here. W hile these 
three modules round out the package for 
general use, they are of less concern to 
us than Animator, which is packed with 
useful animating and editing features 
that can help you introduce interesting 
effects to existing animation files or cre- 
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ate new ones from the ground up. 

The first thing that struck me 
about this new product was the manu- 
al. That is, the— as in one, singular- 
manual, rather than the collection of 
weighty tomes traditionally received 
with an Autodesk title. W e're not talk- 
ing about a thick book here, either; as 
software reference goes, this verges on 
slender. Online help duplicates infor- 
mation from the manual and adds to it, 
and as a nice extra allows you to add 
your own notes and bookmarks to 
return you to sections you use most. As 
this package is not short on features, it 
is a testimony to the usable nature of 
the interface that one slim volume 
proves sufficient. 

That interface remains admirably 
uncluttered despite the wealth of fea- 
tures it manages to support. M ovable 
selection boxes for tools, filters, and 
colors default to a neat, out-of-the way 
row to screen left. When an animation 
is opened, it appears as a filmstrip 
across the top of the screen, while the 
active frame is shown at full size in a 
roomy central work area. Pop-up 
dialogs provide fine-tuning control for 
almost every aspect of this program. n 
a 1,024- by- 780 screen, everything fit 
with room to spare. After working your 
way through a couple of tutorials you'll 
feel right at home with Animator'stools 
and workspace. 

To start with, you can paint into a 
frame to create a new image or alter an 
existing one. T o do so, you select one of 
several available brushes. Brushes can 
also be customized, though not to the 
degree possible in Painter. Pressure sen- 
sitivity is supported for stylus users, and 
there is also an airbrush tool with vari- 
able controls, and the usual straight- 
line, curved-line, and rectangle tools. 
Compared to Painter, these provisions 
seem somewhat skimpy, but they fulfill 
the basics. U sing a stylus and the onion- 
skin feature you can create nice hand- 
drawn animations, and a multiple undo 
lets you easily fix slip-ups. T he real 
strengths of the program, however, are 
its labor-and-time-saving animation 
shortcuts and a useful array of sophisti- 
cated editing capabilities. 



A range of about thirty "inks" are 
really filters for applying special effects. 
T hese include such nifty items as C lone 
ink, which copies brushstroke by brush- 
stroke the area you paint into with it; 
C olorize ink, which adds only hue, leav- 
ing lightness values unaffected (sort of 
like coloring over a black-and-white 
photo with a translucent marker); Soft- 
en ink, which gently blurs an area; and 
Jumble ink, which adds a more chaotic 
blurring effect. T hese and the rest of the 
ink choices allow you to really tailor the 
appearance of an animation to meet 
your needs. 

Another useful ink selection pro- 
vided by A nimator is A Ipha ink. In 
addition to color-keyed alpha channel 
support, this allows you to affect the 
opacity of a specific area by painting 
into it. In addition to increased com- 
positing possibilities, this lets you 
remove unwanted elements from an ani- 
mation by rendering them transparent. 
So you can, for instance, mark up the 
frame with guidelines to indicate the 
paths of animated objects, then use 
clone ink to make the guidelines invisi- 
ble when you're done with them. Used 
in conjunction with onionskinning, this 
can really facilitate hand-drawn anima- 
tions. A nime, anyone? 

Perhaps best of all, the selection 
tools in Animator are flexible and 
sophisticated. By keying on the back- 
ground color with the M agic W and 
tool, for example, you can select out the 
entire background, leaving the fore- 
ground object for you to cut and com- 
posite or modify with some other effect. 
You can instantly apply this sort of 
selection over time to affect a segment 
so that you don't need to work frame by 
frame. It is also possible to add to a 
selection before acting on it, so several 
areas within a frame can be indicated 
and edited as one. 

A selection— even one spanning 
multiple frames— can be saved as a 
sprite and then painted into a different 
animation. When you add an animated 
sprite to a movie, its movement is auto- 
matically extrapolated over the segment. 
You can then modify the sprite's 
motion path by clicking and dragging 



handles along its course, which can 
really help fine-tune a movement. Ani- 
mator also provides predefined Action 
E nvelopes that can be applied to a 
sprite to automatically cause its move- 
ment to gradually accelerate or deceler- 
ate as it progresses. 

D efining a segment creates two 
keyframes as the start and finish of that 
segment and you can easily apply 
desired changes over time between these 
keyframes. These changes can include 
color interpolation (a gradual shift from 
one color to another), morphing one 
shape into another (as long as both 
comprise the same number of vertices), 
and movement of an object from one 
area of the picture frame to another. All 
that is required is to set the first and last 
keyframes. The in-between transition is 
then automated. 

The selecting and editing features 
of A nimator provide some powerful and 
flexible tools for altering and composit- 
ing digitized video or animations you 
might already have made in a three- 
dimensional program or elsewhere. To 
expand on that flexibility, Animator is 
compatible with Photoshop plug-ins 
and, for its initial release, is being bun- 
dled with a special Kai's Power Tools 
package that includes G radient D esign- 
er. This adds such an abundance of 
functionality to Animator right out of 
the box that you'll not soon run out of 
new looks to bring to your animations. 

W hen there are no surprises left for 
the artist, few are to be expected for the 
audience. It should be our task to con- 
tribute what we can to keep game play- 
ers in a continual state of surprise, won- 
derment, and delight, and that means 
never getting too comfortable with the 
way we do things so that players never 
get bored with what they're seeing. 
These are just two possible tools that 
might help you bring your graphics to 
the next level, and bring the players with 
you. W hich is, after all, where you want 
to keep them. ■ 

D avid Sieks is a contributing editor 
to Game Developer. Contact him via e- 
mail at dsieks@arnarb.harvard.edu or 
through Game Developer magazine. 
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